nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-22 00:25:50 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge pull request #1012 from AsaiToshiya/patch-4

Browse Source 
NIP-59: fix typo and nitpicks
This commit is contained in:
Vitor Pamplona 2024-01-31 10:13:23 -05:00 committed by GitHub
commit 735134a301
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
59.md
View File

@ -58,7 +58,7 @@ Tags MUST must always be empty in a `kind:13`. The inner event MUST always be un
## 3. Gift Wrap Event Kind
A `gift wrap` event is a `kind:1059` event that wraps any other event. `tags` SHOULD include any information
needed to route the event to its intended recipient, including the recipient's `p` tag or NIP-13 proof of work.
needed to route the event to its intended recipient, including the recipient's `p` tag or [NIP-13](13.md) proof of work.
```js
{
@ -74,7 +74,7 @@ needed to route the event to its intended recipient, including the recipient's `
# Encrypting Payloads
Encryption is done following NIP-44 on the JSON-encoded event. Place the the encryption payload in the `.content`
Encryption is done following [NIP-44](44.md) on the JSON-encoded event. Place the encryption payload in the `.content`
of the wrapper event (either a `seal` or a `gift wrap`).
# Other Considerations
@ -87,13 +87,13 @@ time-analysis attacks. Note that some relays don't serve events dated in the fut
SHOULD be in the past.
Relays may choose not to store gift wrapped events due to them not being publicly useful. Clients MAY choose
to attach a certain amount of proof-of-work to the wrapper event per NIP-13 in a bid to demonstrate that
to attach a certain amount of proof-of-work to the wrapper event per [NIP-13](13.md) in a bid to demonstrate that
the event is not spam or a denial-of-service attack.
To protect recipient metadata, relays SHOULD guard access to kind 1059 events based on user AUTH. When
To protect recipient metadata, relays SHOULD guard access to `kind 1059` events based on user AUTH. When
possible, clients should only send wrapped events to relays that offer this protection.
To protect recipient metadata, relays SHOULD only serve kind 1059 events intended for the marked recipient.
To protect recipient metadata, relays SHOULD only serve `kind 1059` events intended for the marked recipient.
When possible, clients should only send wrapped events to `read` relays for the recipient that implement
AUTH, and refuse to serve wrapped events to non-recipients.