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:

[
  "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:

[
  "REQ",
  "<subscriptionId>",
  {
    "#m": ["00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048"]
  }
]

Use Cases

Subreddit/IRC-like channels (e.g. { "#m": ["#newbies", "r/nostr", "#mp3s", "r/oldschoolcool"] }) over Nostr.
Forums over Nostr. (e.g. { "#m": ["itguys.com/IT/Support/Hardware", "itguys.com/General/Announcements", "itguys.com/General/New Users", "itguys.com/Social/Memes"] })
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.
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.
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.
Live events can take advantage of ephemeral events and previously-shared multicast group for communication during the event.
Smart contracts may communicate in privacy-preserving way with individual clients using unique short-lived multicast groups.
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.
Testnet-like multicast group for debugging in Nostr.

Notes

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.
Multicast groups are not a replacement for encrypted direct messages but can work in conjunction.

3.8 KiB Raw Blame History