From b9c9a3409e1b40f70aed01b3d604326cb437e733 Mon Sep 17 00:00:00 2001 From: Vitor Pamplona Date: Thu, 28 Mar 2024 19:15:09 -0400 Subject: [PATCH] Typos --- 59.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/59.md b/59.md index 8277c8b..a141ef3 100644 --- a/59.md +++ b/59.md @@ -17,14 +17,14 @@ This NIP relies on [NIP-44](./44.md)'s versioned encryption algorithms. This NIP uses three main primitives to protect the metadata of an event: `rumor`s, `seal`s, and `gift wrap`s. - A `rumor` is any unsigned nostr event. If it is leaked, it cannot be verified. -- A `seal` signs the encrypted rumor in it's `.content`, making the rumor verifiable without revealing it. +- A `seal` signs the encrypted rumor in its `.content`, making the rumor verifiable without revealing it. - A `gift wrap` encrypts any other signed event using random private keys to a known destination in its `tags`. The rumor carries the content itself but if it leaks it will be rejected by relays and clients and can't be authenticated. This provides a measure of deniability. The `seal` exposes the signer, but not the contents or the receiver. The `gift wrap` exposes the receiver, or an alias to the receiver, but not the signer. -The 3 primitives can be used together or separatedly depending on the application. +The 3 primitives can be used together or separately depending on the application. ## The Seal Event Kind @@ -74,7 +74,7 @@ Relays SHOULD only serve `kind 1059` events intended for the marked recipient ba Clients SHOULD only send wrapped events to destination relays that offer this protection. -Relays MAY choose not to store Gift-wrapped events due to them not being publicly useful. Clients MAY choose +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](13.md) in a bid to demonstrate that the event is not spam or a denial-of-service attack.