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

doc: describe event content

Browse Source
This commit is contained in:
Vlad Stan 2023-04-10 15:46:33 +03:00 committed by GitHub
parent cf3594dd51
commit f4be509e10
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 13 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
705.md
View File

@ -18,25 +18,33 @@ Any client can ask its peers to re-publish messages on its behalf. The simplifie
- `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 a `kind:4` 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 coming from `Carol` instead of `Alice`
People can easily run very lightweight republish services for free and provide anonymity for everybody else. People can easily run very lightweight republish services for free and provide anonymity for everybody else.
## Implementation ## Implementation
Define a new very generic `republish` event with `kind:20001` (ephemeral) in the form: Define a new [NIP-16](https://github.com/nostr-protocol/nips/blob/master/16.md) `republish` event with `kind:20001` (ephemeral) in the form:
```json ```json
{ {
... ...
"kind": 20001, "kind": 20001,
"content": <encrypted JSON of the event that is to be republished>, "content": <encrypted JSON of the event(s) that is to be republished>,
"tags": [ "tags": [
["p", <pubkey of the person that is chosen to republish this>], ["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"] ["relays", "wss://somerelay.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. Whenever the chosen `re-publisher` sees a note like that, they automatically decrypt it using [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. - 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 with the same underlying encrypted event.
- there could be multiple nested levels of republish events. - 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):
```json
{
"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)>
}
```