From ffe6a49557253a1f6227793787c6fcf58565a980 Mon Sep 17 00:00:00 2001 From: Jeff Thibault Date: Fri, 10 Feb 2023 08:18:40 -0500 Subject: NIP-04: clarify how shared secret is computed --- 04.md | 2 ++ 1 file changed, 2 insertions(+) (limited to '04.md') diff --git a/04.md b/04.md index 723bd70..0ebcddb 100644 --- a/04.md +++ b/04.md @@ -14,6 +14,8 @@ A special event with kind `4`, meaning "encrypted direct message". It is suppose **`tags`** MAY contain an entry identifying the previous message in a conversation or a message we are explicitly replying to (such that contextual, more organized conversations may happen), in the form `["e", ""]`. +**Note**: By default in the [libsecp256k1](https://github.com/bitcoin-core/secp256k1) ECDH implementation, the secret is the SHA256 hash of the shared point (both X and Y coorinates). In Nostr, only the X coordinate of the shared point is used as the secret and it is NOT hashed. If using libsecp256k1, a custom function that copies the X coordinate must be passed as the `hashfp` argument in `secp256k1_ecdh`. See [here](https://github.com/bitcoin-core/secp256k1/blob/master/src/modules/ecdh/main_impl.h#L29). + Code sample for generating such an event in JavaScript: ```js -- cgit v1.2.3 From 2a4c44035e56580fb22929972a69280236663557 Mon Sep 17 00:00:00 2001 From: Brandon Lucas Date: Wed, 22 Feb 2023 19:14:07 -0500 Subject: Fix minor typo Fix spelling of `coordinates` in Note --- 04.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to '04.md') diff --git a/04.md b/04.md index 0ebcddb..bafc5c7 100644 --- a/04.md +++ b/04.md @@ -14,7 +14,7 @@ A special event with kind `4`, meaning "encrypted direct message". It is suppose **`tags`** MAY contain an entry identifying the previous message in a conversation or a message we are explicitly replying to (such that contextual, more organized conversations may happen), in the form `["e", ""]`. -**Note**: By default in the [libsecp256k1](https://github.com/bitcoin-core/secp256k1) ECDH implementation, the secret is the SHA256 hash of the shared point (both X and Y coorinates). In Nostr, only the X coordinate of the shared point is used as the secret and it is NOT hashed. If using libsecp256k1, a custom function that copies the X coordinate must be passed as the `hashfp` argument in `secp256k1_ecdh`. See [here](https://github.com/bitcoin-core/secp256k1/blob/master/src/modules/ecdh/main_impl.h#L29). +**Note**: By default in the [libsecp256k1](https://github.com/bitcoin-core/secp256k1) ECDH implementation, the secret is the SHA256 hash of the shared point (both X and Y coordinates). In Nostr, only the X coordinate of the shared point is used as the secret and it is NOT hashed. If using libsecp256k1, a custom function that copies the X coordinate must be passed as the `hashfp` argument in `secp256k1_ecdh`. See [here](https://github.com/bitcoin-core/secp256k1/blob/master/src/modules/ecdh/main_impl.h#L29). Code sample for generating such an event in JavaScript: -- cgit v1.2.3 From d97928bd9024a988be6c9f7ec18c0fcf93a8b9a3 Mon Sep 17 00:00:00 2001 From: ennmichael Date: Sun, 5 Mar 2023 21:43:14 +0100 Subject: avoid using substr in NIP-04 example --- 04.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to '04.md') diff --git a/04.md b/04.md index bafc5c7..153456a 100644 --- a/04.md +++ b/04.md @@ -23,7 +23,7 @@ import crypto from 'crypto' import * as secp from 'noble-secp256k1' let sharedPoint = secp.getSharedSecret(ourPrivateKey, '02' + theirPublicKey) -let sharedX = sharedPoint.substr(2, 64) +let sharedX = sharedPoint.slice(2, 67) let iv = crypto.randomFillSync(new Uint8Array(16)) var cipher = crypto.createCipheriv( -- cgit v1.2.3 From a8fab58526f3cafa9d511512e2881f505fbe1626 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Tue, 7 Mar 2023 07:31:21 -0300 Subject: add security warning on nip-04. --- 04.md | 4 ++++ 1 file changed, 4 insertions(+) (limited to '04.md') diff --git a/04.md b/04.md index 153456a..63b1177 100644 --- a/04.md +++ b/04.md @@ -43,3 +43,7 @@ let event = { content: encryptedMessage + '?iv=' + ivBase64 } ``` + +## Security Warning + +This standard does not go anywhere near what is considered the state-of-the-art in encrypted communication between peers, and it leaks metadata in the events, therefore it must not be used for anything you really need to keep secret, and only with relays that use `AUTH` to restrict who can read your `kind:4` events. -- cgit v1.2.3 From a4ed9689032a6e16eff92994195f273e74475f45 Mon Sep 17 00:00:00 2001 From: Jeff Thibault Date: Thu, 9 Mar 2023 11:05:45 -0500 Subject: Update 04.md --- 04.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to '04.md') diff --git a/04.md b/04.md index 63b1177..1866970 100644 --- a/04.md +++ b/04.md @@ -46,4 +46,4 @@ let event = { ## Security Warning -This standard does not go anywhere near what is considered the state-of-the-art in encrypted communication between peers, and it leaks metadata in the events, therefore it must not be used for anything you really need to keep secret, and only with relays that use `AUTH` to restrict who can read your `kind:4` events. +This standard does not go anywhere near what is considered the state-of-the-art in encrypted communication between peers, and it leaks metadata in the events, therefore it must not be used for anything you really need to keep secret, and only with relays that use `AUTH` to restrict who can fetch your `kind:4` events. -- cgit v1.2.3 From b2c21ab10c06be0976a08920c07f5421d17c0654 Mon Sep 17 00:00:00 2001 From: fcked Date: Mon, 13 Mar 2023 16:59:29 +0100 Subject: NIP-04: fix bug in code sample The code sample assumed that a `Uint8Array` was actually a hex string. --- 04.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to '04.md') diff --git a/04.md b/04.md index 1866970..350f9c0 100644 --- a/04.md +++ b/04.md @@ -23,12 +23,12 @@ import crypto from 'crypto' import * as secp from 'noble-secp256k1' let sharedPoint = secp.getSharedSecret(ourPrivateKey, '02' + theirPublicKey) -let sharedX = sharedPoint.slice(2, 67) +let sharedX = sharedPoint.slice(1, 33) let iv = crypto.randomFillSync(new Uint8Array(16)) var cipher = crypto.createCipheriv( 'aes-256-cbc', - Buffer.from(sharedX, 'hex'), + Buffer.from(sharedX), iv ) let encryptedMessage = cipher.update(text, 'utf8', 'base64') -- cgit v1.2.3 From a886b43b48d3e52441bf97e1aa0de39ac2560843 Mon Sep 17 00:00:00 2001 From: fcked Date: Mon, 13 Mar 2023 18:29:24 +0100 Subject: NIP-04 follow up: use new import in code sample --- 04.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to '04.md') diff --git a/04.md b/04.md index 350f9c0..f34d09b 100644 --- a/04.md +++ b/04.md @@ -20,7 +20,7 @@ Code sample for generating such an event in JavaScript: ```js import crypto from 'crypto' -import * as secp from 'noble-secp256k1' +import * as secp from '@noble/secp256k1' let sharedPoint = secp.getSharedSecret(ourPrivateKey, '02' + theirPublicKey) let sharedX = sharedPoint.slice(1, 33) -- cgit v1.2.3 From 56f84f79bd720912d08f5a7172011f7bf647b253 Mon Sep 17 00:00:00 2001 From: Bartholomew Joyce Date: Thu, 23 Mar 2023 08:54:22 -0600 Subject: Added NIP-04 metadata leak warning --- 04.md | 4 ++++ 1 file changed, 4 insertions(+) (limited to '04.md') diff --git a/04.md b/04.md index f34d09b..60ec5e0 100644 --- a/04.md +++ b/04.md @@ -47,3 +47,7 @@ let event = { ## Security Warning This standard does not go anywhere near what is considered the state-of-the-art in encrypted communication between peers, and it leaks metadata in the events, therefore it must not be used for anything you really need to keep secret, and only with relays that use `AUTH` to restrict who can fetch your `kind:4` events. + +## Client Implementation Warning + +Client's *should not* search and replace public key or note references from the `.content`. If processed like a regular text note (where `@npub...` is replaced with `#[0]` with a `["p", "..."]` tag) the tags are leaked and the mentioned user will receive the message in their inbox. -- cgit v1.2.3 From 3cec80d99ebbee6b72aae31f1856181d04971244 Mon Sep 17 00:00:00 2001 From: vivganes Date: Fri, 7 Apr 2023 17:38:03 +0530 Subject: fix grammar and typos --- 04.md | 2 +- 05.md | 2 +- 11.md | 8 ++++---- 13.md | 2 +- 22.md | 2 +- 25.md | 2 +- 40.md | 2 +- 45.md | 2 +- 51.md | 2 +- 78.md | 2 +- 10 files changed, 13 insertions(+), 13 deletions(-) (limited to '04.md') diff --git a/04.md b/04.md index 60ec5e0..6e45b74 100644 --- a/04.md +++ b/04.md @@ -50,4 +50,4 @@ This standard does not go anywhere near what is considered the state-of-the-art ## Client Implementation Warning -Client's *should not* search and replace public key or note references from the `.content`. If processed like a regular text note (where `@npub...` is replaced with `#[0]` with a `["p", "..."]` tag) the tags are leaked and the mentioned user will receive the message in their inbox. +Clients *should not* search and replace public key or note references from the `.content`. If processed like a regular text note (where `@npub...` is replaced with `#[0]` with a `["p", "..."]` tag) the tags are leaked and the mentioned user will receive the message in their inbox. diff --git a/05.md b/05.md index 992983f..a7b42b0 100644 --- a/05.md +++ b/05.md @@ -64,7 +64,7 @@ For example, if after finding that `bob@bob.com` has the public key `abc...def`, ### Public keys must be in hex format -Keys must be returned in hex format. Keys in NIP-19 `npub` format are are only meant to be used for display in client UIs, not in this NIP. +Keys must be returned in hex format. Keys in NIP-19 `npub` format are only meant to be used for display in client UIs, not in this NIP. ### User Discovery implementation suggestion diff --git a/11.md b/11.md index f97193c..1766320 100644 --- a/11.md +++ b/11.md @@ -154,7 +154,7 @@ all, and preferably an error will be provided when those are received. `retention` is a list of specifications: each will apply to either all kinds, or a subset of kinds. Ranges may be specified for the kind field as a tuple of inclusive start and end values. Events of indicated kind (or all) are then limited to a `count` -and or time period. +and/or time period. It is possible to effectively blacklist Nostr-based protocols that rely on a specific `kind` number, by giving a retention time of zero for those `kind` values. @@ -175,8 +175,8 @@ It is not possible to describe the limitations of each country's laws and policies which themselves are typically vague and constantly shifting. Therefore, this field allows the relay operator to indicate which -country's' laws might end up being enforced on them, and then -indirectly on their users's content. +countries' laws might end up being enforced on them, and then +indirectly on their users' content. Users should be able to avoid relays in countries they don't like, and/or select relays in more favourable zones. Exposing this @@ -220,7 +220,7 @@ To support this goal, relays MAY specify some of the following values. the major languages spoken on the relay. - `tags` is a list of limitations on the topics to be discussed. - For example `sfw-only` indicates hat only "Safe For Work" content + For example `sfw-only` indicates that only "Safe For Work" content is encouraged on this relay. This relies on assumptions of what the "work" "community" feels "safe" talking about. In time, a common set of tags may emerge that allow users to find relays that suit diff --git a/13.md b/13.md index cf28d86..e3662a5 100644 --- a/13.md +++ b/13.md @@ -90,4 +90,4 @@ $ echo '["REQ", "subid", {"ids": ["000000000"]}]' | websocat wss://some-relay.c Delegated Proof of Work ----------------------- -Since the `NIP-01` note id does not commit to any signature, PoW can be outsourced to PoW providers, perhaps for a fee. This provides a way for clients to get their messages out to PoW-restricted relays without having to do any work themselves, which is useful for energy constrained devices like on mobile +Since the `NIP-01` note id does not commit to any signature, PoW can be outsourced to PoW providers, perhaps for a fee. This provides a way for clients to get their messages out to PoW-restricted relays without having to do any work themselves, which is useful for energy-constrained devices like mobile phones. diff --git a/22.md b/22.md index fb29e6a..2172519 100644 --- a/22.md +++ b/22.md @@ -22,7 +22,7 @@ This NIP formalizes restrictions on event timestamps as accepted by a relay and The event `created_at` field is just a unix timestamp and can be set to a time in the past or future. Relays accept and share events dated to 20 years ago or 50,000 years in the future. This NIP aims to define a way for relays that do not want to store events with *any* timestamp to set their own restrictions. -[Replaceable events](16.md#replaceable-events) can behave rather unexpected if the user wrote them - or tried to write them - with a wrong system clock. Persisting an update with a backdated system now would result in the update not getting persisted without a notification and if they did the last update with a forward dated system, they will again fail to do another update with the now correct time. +[Replaceable events](16.md#replaceable-events) can behave rather unexpectedly if the user wrote them - or tried to write them - with a wrong system clock. Persisting an update with a backdated system now would result in the update not getting persisted without a notification and if they did the last update with a forward dated system, they will again fail to do another update with the now correct time. A wide adoption of this NIP could create a better user experience as it would decrease the amount of events that appear wildly out of order or even from impossible dates in the distant past or future. diff --git a/25.md b/25.md index 5ab1553..f74bcc0 100644 --- a/25.md +++ b/25.md @@ -16,7 +16,7 @@ A reaction with `content` set to `-` SHOULD be interpreted as a "dislike" or "downvote". It SHOULD NOT be counted as a "like", and MAY be displayed as a downvote or dislike on a post. A client MAY also choose to tally likes against dislikes in a reddit-like system of upvotes and downvotes, or display them as -separate tallys. +separate tallies. The `content` MAY be an emoji, in this case it MAY be interpreted as a "like" or "dislike", or the client MAY display this emoji reaction on the post. diff --git a/40.md b/40.md index 274ee80..32680db 100644 --- a/40.md +++ b/40.md @@ -43,7 +43,7 @@ Clients SHOULD ignore events that have expired. Relay Behavior -------------- -Relays MAY NOT delete an expired message immediately on expiration and MAY persist them indefinitely. +Relays MAY NOT delete expired messages immediately on expiration and MAY persist them indefinitely. Relays SHOULD NOT send expired events to clients, even if they are stored. Relays SHOULD drop any events that are published to them if they are expired. An expiration timestamp does not affect storage of ephemeral events. diff --git a/45.md b/45.md index cd81c11..28e5e96 100644 --- a/45.md +++ b/45.md @@ -6,7 +6,7 @@ Event Counts `draft` `optional` `author:staab` -Relays may support the `COUNT` verb, which provide a mechanism for obtaining event counts. +Relays may support the `COUNT` verb, which provides a mechanism for obtaining event counts. ## Motivation diff --git a/51.md b/51.md index b4143ad..34a5def 100644 --- a/51.md +++ b/51.md @@ -10,7 +10,7 @@ A "list" event is defined as having a list of public and/or private tags. Public If a list type should only be defined once per user (like the 'Mute' list), the list type's events should follow the specification for [NIP-16 - Replaceable Events](16.md). These lists may be referred to as 'replaceable lists'. -Otherwise the list type's events should follow the specification for [NIP-33 - Parameterized Replaceable Events](33.md), where the list name will be used as the 'd' parameter. These lists may be referred to as 'parameterized replaceable lists'. +Otherwise, the list type's events should follow the specification for [NIP-33 - Parameterized Replaceable Events](33.md), where the list name will be used as the 'd' parameter. These lists may be referred to as 'parameterized replaceable lists'. ## Replaceable List Event Example diff --git a/78.md b/78.md index 175f66b..10ff535 100644 --- a/78.md +++ b/78.md @@ -8,7 +8,7 @@ Arbitrary custom app data The goal of this NIP is to enable [remoteStorage](https://remotestorage.io/)-like capabilities for custom applications that do not care about interoperability. -Even though interoperability is great, some apps do not want or do not need interoperability, and it that wouldn't make sense for them. Yet Nostr can still serve as a generalized data storage for these apps in a "bring your own database" way, for example: a user would open an app and somehow input their preferred relay for storage, which would then enable these apps to store application-specific data there. +Even though interoperability is great, some apps do not want or do not need interoperability, and it wouldn't make sense for them. Yet Nostr can still serve as a generalized data storage for these apps in a "bring your own database" way, for example: a user would open an app and somehow input their preferred relay for storage, which would then enable these apps to store application-specific data there. ## Nostr event -- cgit v1.2.3