mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-23 00:45:53 -05:00
86 lines
3.8 KiB
Markdown
86 lines
3.8 KiB
Markdown
NIP-27
|
|
======
|
|
|
|
Multicasting
|
|
------------
|
|
|
|
`draft` `optional` `author:cameri`
|
|
|
|
A new tag `m` meaning `multicast group` allow for events to be addressed to a
|
|
group of clients simultaneously. Multicast in this scenario can be one-to-many
|
|
or many-to-many.
|
|
|
|
A relay MUST forward events containing `m` tags strictly to clients subscribed
|
|
with a tag filter `#m` containing at least one of the values of such tags and
|
|
refrain from forwarding such events to clients without such filter. The value
|
|
of an `m` tag is case-sensitive.
|
|
|
|
A client SHOULD send events containing `m` tags only to relays that explicitly
|
|
support NIP-27. A NIP-16 supporting client MAY test for the capability by
|
|
subscribing twice to a relay with and without the tag filter `#m` respectively
|
|
and sending an ephemeral event with a random `m` tag of equal value and assert
|
|
it was only received by the right subscription.
|
|
|
|
## Events
|
|
|
|
Clients targeting a multicast group MAY include an `m` tag with a value set to
|
|
an arbitrary string representing the multicast group.
|
|
|
|
Suppose that Alice wants to multicast an event to a very special multicast group
|
|
that covers specific topics. The multicast group is identified by the following
|
|
string: `00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048`
|
|
|
|
Alice would construct the following message and send it to her favorite relay
|
|
which happens to support multicasting:
|
|
|
|
```json
|
|
[
|
|
"EVENT",
|
|
{
|
|
"id": "<id>",
|
|
"pubkey": "<Alice's pubkey>",
|
|
"created_at": 1231469640,
|
|
"content": "Let's get the conversation started",
|
|
"tags": [
|
|
["m", "00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048"],
|
|
],
|
|
"sig": "<sig>"
|
|
}
|
|
]
|
|
```
|
|
|
|
## Subscriptions
|
|
|
|
Clients subscribing to a multicast group MUST include an `#m` tag filter with
|
|
an array of multicast groups as values.
|
|
|
|
Suppose that Bob and Charlie both share Alice's interest and would like to stay
|
|
up to date. Both would construct the following message to subscribe:
|
|
|
|
```json
|
|
[
|
|
"REQ",
|
|
"<subscriptionId>",
|
|
{
|
|
"#m": ["00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048"]
|
|
}
|
|
]
|
|
```
|
|
|
|
# Use Cases
|
|
|
|
1. Subreddit/IRC-like channels (e.g. `{ "#m": ["#newbies", "r/nostr", "#mp3s", "r/oldschoolcool"] }`) over Nostr.
|
|
2. Forums over Nostr. (e.g. `{ "#m": ["itguys.com/IT/Support/Hardware", "itguys.com/General/Announcements", "itguys.com/General/New Users", "itguys.com/Social/Memes"] }`)
|
|
3. Clients wishing to filter out all the noise from public events may choose to only subscribe to multicast groups. Apps/games/bots leveraging Nostr may prefer communicating over a multicast group to avoid collision with the broader public.
|
|
4. A hard-to-guess multicast group can be used for increased (but not total) privacy over a trusted relay. A "channel-hopping" algorithm shared by clients may improve privacy in this scenario where a channel is a multicast group.
|
|
5. Two or more parties may initiate contact publicly using Direct Messaging and agree privately on a hard-to-guess multicast group before continuing their exchange hiding further metadata from being leaked to the public. Parties can re-negotiate a new hard-to-guess multicast group at any point.
|
|
6. Live events can take advantage of ephemeral events and previously-shared multicast group for communication during the event.
|
|
7. Smart contracts may communicate in privacy-preserving way with individual clients using unique short-lived multicast groups.
|
|
8. Clients interested in Bitcoin prices in USD may subscribe to the multicast group "prices:btc:usd". Many providers may publish their events to the same multicast groups.
|
|
9. Testnet-like multicast group for debugging in Nostr.
|
|
|
|
# Notes
|
|
|
|
1. Events sent to multicast groups should be considered public, after all they are readable by relays and can also be reshared by any client subscribed to the multicast group.
|
|
2. Multicast groups are not a replacement for encrypted direct messages but can work in conjunction.
|