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

add missing / to "flavors" in example.

Browse Source
This commit is contained in:
fiatjaf 2023-05-28 21:34:20 -03:00
parent 5084fe2e08
commit c2cecdd668
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
29.md
View File

@ -8,7 +8,7 @@ Simple Group Chat
This NIP defines a model for group chat that relies on relays as ultimate sources of authority. Clients can connect to multiple relays and interact with different groups in each of these relays. A group can live in more than one relay or migrate between relays, but for practical purposes it is expected to rely on a single relay for as long as that is working well. This approach minimizes bandwidth consumption and computation costs and ensures the group can have fine-grained permissions and other niceties commonly expected from any group chat platforms without putting a huge amount of overhead on clients. The fundamental assumption here is that censorship is not a big concern for this kind of application. This NIP defines a model for group chat that relies on relays as ultimate sources of authority. Clients can connect to multiple relays and interact with different groups in each of these relays. A group can live in more than one relay or migrate between relays, but for practical purposes it is expected to rely on a single relay for as long as that is working well. This approach minimizes bandwidth consumption and computation costs and ensures the group can have fine-grained permissions and other niceties commonly expected from any group chat platforms without putting a huge amount of overhead on clients. The fundamental assumption here is that censorship is not a big concern for this kind of application.
Each group has an identifier, which is used as the `d` tag (see [NIP-33](33.md)) in events that hold group metadata. The default top-level group in a relay is identified by `"/"`, with subgroups added after the slash and even deeper subgroups separated by other slashes. The imagined user flow for opening a group is to type a hostname with an optional path suffix. For example, if the user types `pizza.com/` that goes to the top-level group at the `wss://pizza.com` relay. If the user types `pizza.com/flavors` that goes to the group "flavors" on the `wss://pizza.com` relay. Each group has an identifier, which is used as the `d` tag (see [NIP-33](33.md)) in events that hold group metadata. The default top-level group in a relay is identified by `"/"`, with subgroups added after the slash and even deeper subgroups separated by other slashes. The imagined user flow for opening a group is to type a hostname with an optional path suffix. For example, if the user types `pizza.com/` that goes to the top-level group at the `wss://pizza.com` relay. If the user types `pizza.com/flavors` that goes to the group `"/flavors"` on the `wss://pizza.com` relay.
The entire metadata of the group (kinds `39000-3900x`) must only be signed by the relay main pubkey given by the `"pubkey"` field in the relay's [NIP-11](11.md) response. Other metadata events not signed by that public key must be ignored by clients. Upon opening a group, the chat client is supposed to fetch (or use locally cached values) these metadata events in order to render the group details, and then fetch the messages (`kind:9`). The entire metadata of the group (kinds `39000-3900x`) must only be signed by the relay main pubkey given by the `"pubkey"` field in the relay's [NIP-11](11.md) response. Other metadata events not signed by that public key must be ignored by clients. Upon opening a group, the chat client is supposed to fetch (or use locally cached values) these metadata events in order to render the group details, and then fetch the messages (`kind:9`).