nips/705.md

NIP-705

Republish Events by Peers

draft optional author:fiatjaf author:motorina0

This NIP defines a way for a client to indirectly publish events to a relay with the help of its peers.

Motivation

In order to hide their identity from the "general public" clients can use ephemeral keys or one-use-only keys (see NIP704) 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 NIP tries to prevent relays from tracking the interaction between the publishers and the subscribers of events.

Suggestion

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.

Implementation

Define a new NIP-16 republish event with kind:20001 (ephemeral) in the form:

{
  ...
  "kind": 20001,
  "content": <encrypted JSON of the event(s) that is to be republished>,
  "tags": [
    ["p", <pubkey of the person that is chosen to republish this>],
    ["relays", "wss://somerelay.com", "wss://otherrelay.com", "and so on, there could be many of these"]
  ]
}

Whenever the chosen re-publisher sees a note like that, they automatically decrypt it using the 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.

The JSON content (before encription) of the kind:20001 event is of this form (other fields might later be added):

{
  "events": [<list of nostr events to be re-published>],
  "padding": <string (optional), random data used to obfuscate the real size of re-publised event(s)>
}