Mirror/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-14 19:36:22 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

update to reduce the interactivity required.

Browse Source 
based on https://github.com/nostr-protocol/nips/pull/20#issuecomment-1194729229
This commit is contained in:
fiatjaf 2022-07-25 20:15:17 -03:00 committed by William Casarin
parent 3a7b4d8ac0
commit db5b671f3e
1 changed files with 8 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
21.md
View File

@ -8,41 +8,26 @@ Non-public encrypted messages
This NIP defines a method for relays to verify the identity of the client that is requesting ["encrypted directed messages"](04.md) messages and only allow these clients to see messages authored by them or targeted to them. This NIP defines a method for relays to verify the identity of the client that is requesting ["encrypted directed messages"](04.md) messages and only allow these clients to see messages authored by them or targeted to them.
Relays supporting this NIP, upon receiving a `REQ` containing a filter for `kinds: [4]`, MUST reply with a challenge message in the format `["CHALLENGE", "<challenge string>"]`. When connecting to relays that support this NIP, clients SHOULD send a an event of kind `20001`, meaning "client identification", with the content set to `"client identification for <relay hostname>"`.
Clients must then generate an event of kind `20001`, meaning "challenge response", with the content set to `"<relay hostname> challenge for <subscription_id>: <challenge string>"`. The relay MUST then use the event to verify the identity of the client and discard it afterwards. In the verification process the relay MUST check:
The relay MUST then use the event to verify the identity of the client and discard it afterwards. 1. if event signature is valid;
2. if the content phrase matches the canonical phrase with the actual relay hostname in it;
3. if the event timestamp is not too far from the relay current timestamp.
If the signature matches and the event pubkey corresponds to the kind-04 filter -- i.e. the client is not requesting to see messages from other people -- the relay CAN proceed to return the events for the given subscription. If all is well, then the relay can use the identified pubkey to validate further requests for kind-4 events and only return kind-4 events that were either authored by the identified pubkey (`"pubkey": ...`) or are addressed to the identified pubkey (`"tags": ["p", ...]`).
### Example ### Example
1. Client connects to `wss://chat.relay.nostr.com/` 1. Client connects to `wss://chat.relay.nostr.com/`
2. Client sends `["REQ", "my-dms", {"kinds": [4], "#p": ["aeae..."]}, {"kinds": [4],"authors": ["aeae"]}]` 2. Client sends `["EVENT", {"id": "...", "pubkey": "aeae...", "sig": "...", "kind": 20001, "tags": [], "created_at": 1609470000, "content": "client identification for chat.relay.nostr.com"}]`
3. Relay sends `["CHALLENGE", "supertactic"]` 3. Client sends `["REQ", "my-dms", {"kinds": [4], "#p": ["aeae..."]}, {"kinds": [4],"authors": ["aeae"]}]`
4. Client sends `["EVENT", {"id": "...", "pubkey": "aeae...", "sig": "...", "kind": 20001, "tags": [], "created_at": 1609470000, "content": "chat.relay.nostr.com challenge for my-dms: supertactic"}]`
5. Relay sends `["EVENT", "my-dms", {"id": "...", "pubkey": "aeae", "kind": 4, "content": "<encrypted>", "sig": "...", "tags": ["p", "786b..."]}]` 5. Relay sends `["EVENT", "my-dms", {"id": "...", "pubkey": "aeae", "kind": 4, "content": "<encrypted>", "sig": "...", "tags": ["p", "786b..."]}]`
5. Relay sends `["EVENT", "my-dms", {"id": "...", "pubkey": "786b...", "kind": 4, "content": "<encrypted>", "sig": "...", "tags": ["p", "aeae..."]}]` 5. Relay sends `["EVENT", "my-dms", {"id": "...", "pubkey": "786b...", "kind": 4, "content": "<encrypted>", "sig": "...", "tags": ["p", "aeae..."]}]`
Ids and signatures omitted and pubkeys shortened for readability. Ids and signatures omitted and pubkeys shortened for readability.
### Clarifications
- What happens if the client asks for other stuff at the same time? So for example if you request for mutiple keys do you get mutiple challenges, if you ask for other event kinds as same time do they just come back as normal separately?[^q1]
Relays MUST send a single challenge message and clients are expected to send a single challenge response back. If the client for any reason has more than one identity it should use two different subscriptions.
If the filter has other clauses and is requesting other events (non kind-4) the relay SHOULD return these other events as always, and just leave out the kind-4 ones for after the challenge is completed.
Clients MUST send kind-4 requests for a single pubkey (for each subscription), therefore relays SHOULD ignore subscription requests for kind-4 that define multiple pubkeys or no pubkeys at all.
- What if a client wants to grab only direct messages between two parties, for example with a filter like `{"kinds": [4], "authors": ["d3d3..."], "#e": ["8d8d..."]}`?
In this case relays SHOULD check that there is only one pubkey in either `"authors"` and `"#e"` and accept any of those as the challenge response.
[^q1]: https://t.me/nostr_protocol/26059
## Rationale ## Rationale
[NIP-04](04.md) is flawed because its event contents are encrypted, but the metadata around it is not, and by the nature of Nostr as a protocol designed for public communication in general anyone is able to query relays for any event they want -- thus it's possible to anyone to track conversations between any other Nostr users, not _exactly what_ they're saying, but to whom they're chatting and how often. [NIP-04](04.md) is flawed because its event contents are encrypted, but the metadata around it is not, and by the nature of Nostr as a protocol designed for public communication in general anyone is able to query relays for any event they want -- thus it's possible to anyone to track conversations between any other Nostr users, not _exactly what_ they're saying, but to whom they're chatting and how often.