laantungir
/
nostr
mirror of https://github.com/nostr-protocol/nostr.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

improve nip01.

This commit is contained in:
fiatjaf 2021-01-06 09:58:54 -03:00
parent 00e5667471
commit c6dbcba906
1 changed files with 15 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
nips/01.md
View File

@ -35,15 +35,21 @@ Basic protocol flow description
<content>, as a string
]
```
4. Users can connect to any compatible relay by opening a websocket connection to `<relay_url>/ws`. The websocket accepts the following messages:
1. `sub-key:<pubkey, as a hex string>`, subscribes to events from this key ("follow");
2. `unsub-key:<pubkey, as a hex string>`, as above, but unsubscribes ("unfollow");
3. `req-feed:<{limit, offset}, object with these optional parameters>`, requests the latest events from the pubkeys subscribed to above (the basic flow is to open a websocket, call `sub-key` many times, then call `req-feed`).
4. `req-event:<{id, limit}, object with the event id and optional parameters>`, requests one event specifically and other events related to it ("browse a thread").
5. `req-key:<{pubkey, limit, offset}, object with the pubkey and optional parameters>`, requests one pubkey specifically ("browse a user profile").
6. `<event, in object format as noted above>`, publishes an event.
5. There are 3 kinds of messages a user can publish (other NIPs may define different types):
4. Users can connect to any compatible relay by opening a websocket connection to `<relay_url>/ws`. The websocket accepts the following messages, each of it should trigger a different action on their part:
* `sub-key:<pubkey, as a hex string>`, subscribes to events from this key (a client will do this for every key it is "following"), it instructs the relay to send event messages for every new event it sees from this key;
* `unsub-key:<pubkey, as a hex string>`, as above, but unsubscribes ("unfollow"), the opposite of the previous;
* `req-feed:<{limit, offset}, object with these optional parameters>`, requests the latest events from the pubkeys subscribed to above (the basic flow is to open a websocket, call `sub-key` many times, then call `req-feed`), upon receiving this the relay should gather the latest events from all the keys this websocket client has subscribed to with `sub-key` and send them as event messages.
* `req-event:<{id, limit}, object with the event id and optional parameters>`, requests one event specifically and other events related to it ("browse a thread").
* `req-key:<{pubkey, limit, offset}, object with the pubkey and optional parameters>`, requests one pubkey specifically ("browse a user profile").
* `<event, in object format as noted above>`, publishes an event.
5. The websocket will emit two types of messages:
* `[<event>, <context>]`, a JSON array containing an event object and the context in which it is being emitted. The `<context>` is a string with a single letter, which can be:
* "p": Used with events the relay has requested with `req-feed`.
* "n": Used when a new event is received by the relay and propagated to the client which has subscribed to it with `sub-key`.
* "r": Used for events sent in response to `req-event` or `req-key`.
* `["notice", <string>]`, a notice from the relay, either an error message or something else the relay wants to communicate.
6. There are 3 kinds of events can publish (other NIPs may define different types):
- `0`: `set_metadata`: the `content` is set to a stringified JSON object `{name: <string>, about: <string>, picture: <url, string>}` describing the user who created the event. A relay may delete past `set_metadata` events once it gets a new one for the same pubkey.
- `1`: `text_note`: the `content` is set to the text content of a note, anything the user wants to say.
- `2`: `recommend_server`: the `content` is set to the URL (e.g., `https://somerelay.com`) of a relay the event creator wants to recommend to its followers.
6. A relay may choose to treat different message kinds differently (for example, instead of just returning the newest events for a given profile on `req-key` it can choose to always return the latest `set_metadata` event it has even if that is very old, so the client can always see a name and picture when browsing a profile), or apply any arbitrary filtering criteria it desires to the kinds of events it will accept.
7. A relay may choose to treat different message kinds differently (for example, instead of just returning the newest events for a given profile on `req-key` it can choose to always return the latest `set_metadata` event it has even if that is very old, so the client can always see a name and picture when browsing a profile), or apply any arbitrary filtering criteria it desires to the kinds of events it will accept.