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

Update 27.md

Browse Source
This commit is contained in:
Ricardo Arturo Cabral Mejía 2022-08-22 21:25:08 -04:00 committed by GitHub
parent ef1efd0d5f
commit 225e4774c8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 41 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

76
27.md
View File

@ -1,37 +1,33 @@
NIP-27 NIP-27
====== ======
Multicasting Restricted Tags
------------ ---------------
`draft` `optional` `author:cameri` `draft` `optional` `author:cameri`
A new tag `m` meaning `multicast group` allow for events to be addressed to a This NIP extends the `<filters>` object described in `NIP-01` to contain
group of clients simultaneously. Multicast in this scenario can be one-to-many arbitrary two-letter tags (known as restricted tags) prefixed by `#`, allowing
or many-to-many. for events with restricted tags to be queried. Any two-letter key prefixed by
`#` is a restricted tag query and must be an array of strings.
A relay MUST forward events containing `m` tags strictly to clients subscribed The filter condition matches an event if and only if all of the restricted tags
with a tag filter `#m` containing at least one of the values of such tags and in the event are also present in a `<filters>` object. As such, relays should not
refrain from forwarding such events to clients without such filter. The value forward events with restricted tags to clients without a strictly matching filter.
of an `m` tag is case-sensitive.
A client SHOULD send events containing `m` tags only to relays that explicitly A client wishing to use restricted tags should only send events with restricted
support NIP-27. A NIP-16 supporting client MAY test for the capability by tags to relays that explicitly support NIP-27.
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 ## Events
Clients targeting a multicast group MAY include an `m` tag with a value set to Clients wishing to send an event with a restricted tag may include one or more
an arbitrary string representing the multicast group. two-letter tags with a value set to an arbitrary string.
Suppose that Alice wants to multicast an event to a very special multicast group Suppose that Alice wants to send an event with the restricted tag `#ch`. The value
that covers specific topics. The multicast group is identified by the following of the `#ch` restricted tag is the following string: `/nostr/social`
string: `00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048`
Alice would construct the following message and send it to her favorite relay Alice would construct the following message and send it to her favorite relay
which happens to support multicasting: which happens to support restricted events:
```json ```json
[ [
@ -42,7 +38,7 @@ which happens to support multicasting:
"created_at": 1231469640, "created_at": 1231469640,
"content": "Let's get the conversation started", "content": "Let's get the conversation started",
"tags": [ "tags": [
["m", "00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048"], ["ch", "/nostr/social"],
], ],
"sig": "<sig>" "sig": "<sig>"
} }
@ -51,8 +47,8 @@ which happens to support multicasting:
## Subscriptions ## Subscriptions
Clients subscribing to a multicast group MUST include an `#m` tag filter with Clients wishing to subscribe to events with restricted tags MUST include a filter
an array of multicast groups as values. that matches all of the restricted tags in said events.
Suppose that Bob and Charlie both share Alice's interest and would like to stay 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: up to date. Both would construct the following message to subscribe:
@ -62,24 +58,34 @@ up to date. Both would construct the following message to subscribe:
"REQ", "REQ",
"<subscriptionId>", "<subscriptionId>",
{ {
"#m": ["00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048"] "#ch": ["/nostr/social"]
} }
] ]
``` ```
# Use Cases # Use Cases
1. Subreddit/IRC-like channels (e.g. `{ "#m": ["#newbies", "r/nostr", "#mp3s", "r/oldschoolcool"] }`) over Nostr. 1. Subreddit/IRC-like channels (e.g. `{ "#ch": ["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"] }`) 2. Forums. (e.g. General/Support subforum at itguys.com forum
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. `{ "#fr": ["itguys.com"], "#sb": ["General/Support"] }`)
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. 3. Clients wishing to filter out all the noise from the broad public events may
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. choose to only subscribe to events with restricted tags. Apps/games/bots leveraging
6. Live events can take advantage of ephemeral events and previously-shared multicast group for communication during the event. Nostr may prefer communicating using NIP-27 to namespace their communications.
7. Smart contracts may communicate in privacy-preserving way with individual clients using unique short-lived multicast groups. 4. A restricted tag with a hard-to-guess value can be used for increased isolation
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. in communications without the expectation of privacy. A "channel-hopping" algorithm
9. Testnet-like multicast group for debugging in Nostr. shared by clients may improve isolation in this scenario.
5. Two or more parties may initiate contact publicly using Direct Messaging to then
upgrade their communications to using events with restricted tags with a hard-to-guess
value before continuing their exchange. Parties can re-negotiate a new hard-to-guess
value at any point.
6. Live events can take advantage of ephemeral events and events with restricted
tags for exclusivity during the event.
7. Smart contracts may communicate with individual clients using events with
restricted tags.
8. Developers debugging in Nostr can use events with restricted tags to avoid spamming
others in public relays.
# Notes # 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. 1. Events with restricted tags are public and offer no privacy.
2. Multicast groups are not a replacement for encrypted direct messages but can work in conjunction.