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

doc: make it more general (not only kind:4)

Browse Source
This commit is contained in:
Vlad Stan 2023-04-27 18:45:29 +03:00
parent a1d24586a2
commit 5a9a766a6b
1 changed files with 8 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
705.md
View File

@ -6,22 +6,21 @@ Republish Encrypted Direct Messages
`draft` `optional` `author:fiatjaf` `author:motorina0`
This NIP defines a way for a client to indirectly publish `kind:4` events to a relay with the help of its peers.
This NIP defines a way for a client to indirectly publish events to a relay with the help of its peers.
## Motivation
One way to increase the privacy of Encrypted Direct Messages ([NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md)) is for peers to derive new `one-use-only` keys when they communicate (see [NIP704](https://github.com/motorina0/nips/blob/dm-one-use-keys/704.md)).
In order to hide their identity from the "general public" clients can use ephemeral keys or `one-use-only` keys (see [NIP704](https://github.com/motorina0/nips/blob/dm-one-use-keys/704.md)) to sign and publish events. However, the relay(s) can still see who is publishing events and who is listening for events with specific public keys (and correlate the two).
This technique hides from the "general public" that two clients are chatting. However, the relay(s) in the middle can still see who is publishing events and who is listening for events with specific public keys (and correlate the two).
This NIP tries to prevent relays from tracking the interaction between the publishers and the subscribers of events.
## Suggestion
Any client can ask its peers to `re-publish` messages on its behalf. The simplified version of the interaction is as follows:
- `Alice` wants to chat with `Bob`. She builds the `kind:4` nostr event but does NOT sent it to the relay(s).
- instead `Alice` creates a `kind:4` event for `Carol` where the content is the event for `Bob`. `Alice` publishes this event to the relay(s).
- `Carol` receives the event, unwrapps it then publishes to the relay(s) the event for `Bob`.
A client can ask its peers to `re-publish` messages on its behalf. The simplified version of the interaction is as follows:
- `Alice` wants to communicate with `Bob`. She builds the nostr event but does NOT send it to the relay(s).
- instead `Alice` creates an event for `Carol` where the content is the event for `Bob`. `Alice` publishes this event to the relay(s).
- `Carol` receives the event, unwrapps it, then publishes to the relay(s) the event for `Bob`.
- the relay(s) see the event as coming from `Carol` instead of `Alice`
People can easily run very lightweight republish services for free and provide anonymity for everybody else.
Re-publish services can also be an optional component of chat clients.
## Implementation
Define a new [NIP-16](https://github.com/nostr-protocol/nips/blob/master/16.md) `republish` event with `kind:20001` (ephemeral) in the form:
@ -39,7 +38,7 @@ Define a new [NIP-16](https://github.com/nostr-protocol/nips/blob/master/16.md)
Whenever the chosen `re-publisher` sees a note like that, they automatically decrypt it using the [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md) method and publish it to the chosen relays.
- the chosen relays could (and probably should) be different from the relay used to broadcast the republish event.
- there could be many republish events with the same underlying encrypted event.
- there could be many republish events within the same underlying encrypted event.
- there could be multiple nested levels of republish events.
The JSON content (before encription) of the `kind:20001` event is of this form (other fields might later be added):