mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-23 08:55:52 -05:00
doc: add implementation
section
This commit is contained in:
parent
6a61ca28ef
commit
f432d36056
26
705.md
26
705.md
|
@ -11,10 +11,32 @@ This NIP defines a way for a client to indirectly publish `kind:4` events to a r
|
||||||
## Motivation
|
## 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)).
|
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)).
|
||||||
|
|
||||||
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.
|
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).
|
||||||
|
|
||||||
## Suggestion
|
## 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).
|
- `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 an event for `Carol` where the content is the event for `Bob`. `Alice` publishes this event 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 and publishes to the relay(s) the event for `Bob`.
|
- `Carol` receives the event, unwrapps it and publishes to the relay(s) the event for `Bob`.
|
||||||
- the relay(s) see the event as comming from `Carol` instead of `Alice`
|
- the relay(s) see the event as comming from `Carol` instead of `Alice`
|
||||||
|
|
||||||
|
People can easily run very lightweight republish services for free and provide anonymity for everybody else.
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
Define a new very generic `republish` event with `kind:20001` (ephemeral) in the form:
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
...
|
||||||
|
"kind": 20001,
|
||||||
|
"content": <encrypted JSON of the event that is to be republished>,
|
||||||
|
"tags": [
|
||||||
|
["p", <pubkey of the person that is chosen to republish this>],
|
||||||
|
["relays", "wss://relay.com", "wss://otherrelay.com", "and so on, there could be many of these"]
|
||||||
|
]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Then whenever the chosen republisher sees a note like that they automatically decrypt it using NIP-04 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 multiple nested levels of republish events.
|
||||||
|
|
Loading…
Reference in New Issue
Block a user