nips
nips copied to clipboard
nostr-protocol
NIP-27 Restricted tags
How is this any different than simply using a hashtag, say like "#subject" and subscribing to that?
How is this any different than simply using a hashtag, say like "#subject" and subscribing to that?
You'll be getting events with a #subject tag even if it's not in your filters. But with this NIP, you won't be getting events with #m tag if you are not explicitly including it in your filters.
so the goal is to conceal the conversation to a kinda secret subscription? I fail to see the benefits of such closed conversation if the m tag is publicly available from Alice initial post. I already showed my interest in Alice's posts by subscribing to her pubkey, now I need to subscribe again for different topics?
so the goal is to conceal the conversation to a kinda secret subscription? I fail to see the benefits of such closed conversation if the m tag is publicly available from Alice initial post. I already showed my interest in Alice's posts by subscribing to her pubkey, now I need to subscribe again for different topics?
I think you'll see it once I add more examples. For now this is what I have in mind when writing this NIP: https://en.m.wikipedia.org/wiki/Multicast
This is not meant to be the enabler of secret communication, or a replacement for DMs, multicasting is still 100% public.
https://en.m.wikipedia.org/wiki/Multicast
I think the difference is that on nostr, relays don't broadcast, it's always unicast based on requests(no?), and with this, what I see is people missing conversations because they didn't know they'd need to subscribe, they'll fail to receive these events, even though they subscribed the pubkey. Maybe like you said, I'll understand better with more examples but I'm not seeing it as is.
Is this just for ephemeral events? I would like to see use cases, but very interesting so far.
Also why not just use the
#mfilter? Maybe add this question to the NIP.
Then it would be a broadcast, and any client subscribing with {} will get the events.
Just like nip-21 non-public DMs, this nip goes against mirroring events between relays but being less about privacy (groups can't hold a secret), maybe the intended goals can be achieved by other means than by excluding m-tagged events from match-all filters {}?
Maybe supporting relays could treat a filter containing ,"m":["!"] not as a no-match filter but as a filter to match anything that has no m-tag. Clients could still mirror all events oblivious of this nip while supporting clients could get the intended behaviour of only getting m-tags they want. Of course sending ,"m":["!"] with all their non-multicast queries will get them empty results from relays that don't support this nip.
Then it would be a broadcast, and any client subscribing with {} will get the events.
But that will happen anyway for relays that do not implement this restriction based on subscription id here.
Hmm, thinking about it I think it would be better to define a thing on the filter side. Like require the client to include the #m filter attribute somehow for these events to be sent to them.
Then it would be a broadcast, and any client subscribing with {} will get the events.
But that will happen anyway for relays that do not implement this restriction based on subscription id here.
Hmm, thinking about it I think it would be better to define a thing on the filter side. Like require the client to include the
#mfilter attribute somehow for these events to be sent to them.
Correct which is why I included in the nip that clients should be reasonable and identify the relay with the capability and only send Multicast events to relays that support it. Clients that dont support nip 27 can send m tags but the behaviour is unexpected. It either gets broadcasted or multicasted depending on the relay, they will have no way of knowing. I've implemented this NIP in Nostr-ts-relay and if the filter does not invlude #m the client won't get the Multicast event.
https://en.m.wikipedia.org/wiki/Multicast
I think the difference is that on nostr, relays don't broadcast, it's always unicast based on requests(no?), and with this, what I see is people missing conversations because they didn't know they'd need to subscribe, they'll fail to receive these events, even though they subscribed the pubkey. Maybe like you said, I'll understand better with more examples but I'm not seeing it as is.
With this NIP we are taking the Multicast concept for network packets and applying it to nostr events.
Would this work as new kind or with existing kinds? Someone who does a like (kind7) on a multicast, does it work the same? I'm starting to understand better the cases where this would make sense, this becomes a chat group essentially. To see the group messages, you need to subscribe to it. Is this a good example?
Might be good to add some motivating examples. I don't know what I would use this for.
I've added use cases hoping to motivate approval/adoption and to elicit further conversation.
Should we just use the tag t (hashtag) or r? It seems like these have similar use cases. Thinking of the single-char economy here.
I immediately see the utility of this and tried (rather incoherently, I think) to propose something similar in a previous PR discussion. Marking a message as "dark" (i.e., only fanned out when explicitly matched by this tag) is a useful means of limiting spammy results in feeds, not to mention making e.g. testing on mainnet a lot less disruptive. There's no major privacy win, but it does limit noise and give folks the ability to publish to a subset of their followers vs. the entire network.
Personally I'd like to adopt it and follow directly with a second tag (or variant form) pm to indicate a "multicast topic" that also applies symmetric en/decryption via a PSK shared out-of-band, or a PAKE signaling channel. That's obviously a discussion for a dedicated PR, though. :)
My main concern with this is that it basically reserves the tag "m" from all other kinds, even if they do not want to participate in multicast. I am still unsure of the advantage over clients simply subscribing to tags if they want to reduce traffic.
It seems like this NIP bakes in the assumption that relays are trustworthy, and the main goal is preventing other clients from seeing their events. That doesn't coincide with my view of the nostr security model (relays are minimally trusted).
It seems like this NIP bakes in the assumption that relays are trustworthy, and the main goal is preventing other clients from seeing their events. That doesn't coincide with my view of the nostr security model (relays are minimally trusted).
Your opinion on #20, please.
Yes, nostr shines for its simplicity and I understand that it's not the place for privacy through fancy crypto but to even mildly imply privacy through trusted relays is also a trap I hope we don't build for people to fall into. Therefore I tend to reject both this and #20.
My main concern with this is that it basically reserves the tag "m" from all other kinds, even if they do not want to participate in multicast. I am still unsure of the advantage over clients simply subscribing to tags if they want to reduce traffic.
It seems like this NIP bakes in the assumption that relays are trustworthy, and the main goal is preventing other clients from seeing their events. That doesn't coincide with my view of the nostr security model (relays are minimally trusted).
I've used m so that relays can index them and following the same pattern as Generic Tag Queries. My relay implementation actually indexes all tag identifiers not just single letters but you can't search for events with them because it is out of spec. I could definitely use a longer tag identifier if this is a deal breaker.
Aside: I don't really buy into the idea that indexable tag identifiers should be one letter to be honest because it's probably just to cope with a limitation of the technology used by other relay implementations.
I added a note to the NIP so there's no baked in assumption on relays being or having to be trustworthy, by saying that events are still considered public. Do you still consider this is still the case? I could reword it to be more explicit.
Do you not foresee users wanting to have separate discussions from the public chatter like its done on forums, IRC channels, etc? Do you think there's any merit in the use cases mentioned? Would love to hear your thoughts more on these other applications enabled.
There's a potential future layer on top of Multicast groups that could make it secure (end to end encrypted) but that's not what I'm trying to achieve here.
If you want to do public group chats on for example kind 42. Who would use kind 42 for broadcasts? All would include the m tag but by returning all kind 42 events on a {"kinds":[42]} filter, at least developers wouldn't fall for the illusion there was anything private about those groups. They would still have to educate the users.
If you claim on the other hand that relays returning all events on a {} filter would lead to people trolling people in their groups, then it would clearly be about privacy. Please pick. Is it or is it not about privacy because if it is not, then there is no reason to exclude all those events.
If you want to do public group chats on for example kind 42. Who would use kind 42 for broadcasts? All would include the
mtag but by returning all kind 42 events on a{"kinds":[42]}filter, at least developers wouldn't fall for the illusion there was anything private about those groups. They would still have to educate the users.If you claim on the other hand that relays returning all events on a
{}filter would lead to people trolling people in their groups, then it would clearly be about privacy. Please pick. Is it or is it not about privacy because if it is not, then there is no reason to exclude all those events.
I think every kind should be able to be sent to Multicast groups otherwise groups would need their own ephemeral/replaceable/notes/and any new kind we come up with in the future won't benefit them so I won't bury this under an event kind. I am okay with rewording the PR to make no mention of privacy other than to say that this does not attempt to provide any privacy and to specify that relays MAY choose whether or not they want to broadcast events for which the client did not specifically provide an #m tag filter. That IMO would make it compatible with existing relays and still allow stricter relays to provide the feature as I originally intended it. I will probably reword this PR to use the word topic instead of Multicast groups and to use tag #t instead of #m.
@Cameri can you define what you mean by "multicast groups"? You keep using this term, but it doesn't have any meaning to me. To me any Nostr filter is a "multicast group", so everything you say just sounds weird. I've opened the Wikipedia page you sent but that didn't clarify anything.
Also I have asked you up there what was the difference between just sending an event with a tag and you said "that would be a broadcast", but the events described in this NIP are also broadcast to anyone who knows the tag, right? I think the fundamental difference must be made clearer. If the difference is the secrecy ensured by relays, I think this NIP must be simplified and reworded to convey that which is the essential feature of it.
@Cameri can you define what you mean by "multicast groups"? You keep using this term, but it doesn't have any meaning to me. To me any Nostr filter is a "multicast group", so everything you say just sounds weird. I've opened the Wikipedia page you sent but that didn't clarify anything.
I understand the name may be confusing because as you imply I also think now that it is too generic, but let me paraphrase it and perhaps you can help me find a better name:
A Multicast group is the name for the set of clients that address each other in each transmission. Any client not part of the set does not receive the transmission which makes it more efficient for relays since they wouldn't be transmitting to all clients.
Perhaps topic would be a better and easier name? Let me know your thoughts, naming is hard.
A Multicast group is the name for the set of clients that address each other in each transmission. Any client not part of the set does not receive the transmission which makes it more efficient for relays since they wouldn't be transmitting to all clients.
So this is the understand I had, which now I see was the correct understanding. In that case I reiterate my position that this is basically what Nostr itself already is: a system for relays to send events only to a set of interested parties.
Also I have asked you up there what was the difference between just sending an event with a tag and you said "that would be a broadcast", but the events described in this NIP are also broadcast to anyone who knows the tag, right? I think the fundamental difference must be made clearer. If the difference is the secrecy ensured by relays, I think this NIP must be simplified and reworded to convey that which is the essential feature of it.
I should probably have elaborated more, but here's what I meant: today and without this NIP, when you send an event every client can receive it by subscribing with an empty filter. Even though you can use filters to limit the scope of the events you receive, your client is still entitled to all events the relay has to offer.
The essential feature of this NIP is that it lets publishers to address just a subset of all the clients, not all. The clients join the set by subscribing by passing a string that identifies the set (which in retrospect I've mistakenly called Multicast groups).
The secrecy comes from the fact that you can name your multicast group/group address/topic with a string that is hard to guess. Imagine having to figure out a 64 character long string to join the set? Won't happen in a lifetime. Relays would have to collude with clients wanting to snoop and relays can always snoop. Using this NIP in conjunction with DMs reduces the amount of metadata leaked, which IMO is an improvement over plain NIP-04.
Even though it is hard to guess a string, anyone part of the group can still reshare an event publicly and relays have always been able to see the filters clients use.
Choosing to only address a set of clients is not censorship or we have to also agree that sending a message on any Telegram/Signal group is censorship because not everyone can see it. The idea that this NIP introduces censorship from relays IMO is unfounded. The relay is not blocking anyone from receiving those events. We are perfectly fine joining subreddits, IRC channels, Telegram channels and groups (even Twitter has chat groups).
When I join the Nostr Telegram group it is because I am interested in communicating with you and others over the same topic: Nostr. If I follow you or anyone else, I'm not necessarily interested in what they post in every group that they could be, I'm interested in what you and others wish to make public.
This NIP adds the ability to keep conversations grouped by topic that only those specifically interested will receive, I just happened to have picked a poor name and perhaps overstated privacy implications.
I appreciate the interest and help on this PR, I believe it has enough merit to deserve its own tag, be it #m, #g or #t or anything else but event kinds.
How about renaming it to NIP-27 Groups / Public Groups, maybe it would clear up some confusion
Even though you can use filters to limit the scope of the events you receive, your client is still entitled to all events the relay has to offer.
"entitled"???
The secrecy comes from the fact that you can name your multicast group/group address/topic with a string that is hard to guess. Imagine having to figure out a 64 character long string to join the set? Won't happen in a lifetime. Relays would have to collude with clients wanting to snoop and relays can always snoop.
So it is about privacy? If it is, the nip is a hard NACK from me as no group beyond 2 members can be kept private. Every participant and the relay have plausible deniability about sharing the secret. Sites could list all those "hard to guess" secrets and offer sats for more. Who's going to stop them?
I also see it as very delicate for the relay provider as it gets access to all those groups. If groups are being used for criminal activity, these infrastructure providers would be in a prime position to police those? I'd much rather not have visibility into such private groups as although you might mention this not being about privacy, it clearly is. Private communication should only happen encrypted.
Using this NIP in conjunction with DMs reduces the amount of metadata leaked, which IMO is an improvement over plain NIP-04.
This assumes the use of ephemeral accounts, which again has spam issues unless you are talking about what #20 which also suggests to hide events from the public eye but with a recipient tag instead of an m-tag. Unless both parties use different m-tags, ... no matter how you spin it, the privileged relay would know who's interested in which DMs, so this would not make #20 better.
Even though it is hard to guess a string, anyone part of the group can still reshare an event publicly and relays have always been able to see the filters clients use.
Reshare ... without the m-tag I assume? That would have no attribution to the original author though.
Choosing to only address a set of clients is not censorship or we have to also agree that sending a message on any Telegram/Signal group is censorship because not everyone can see it. The idea that this NIP introduces censorship from relays IMO is unfounded. The relay is not blocking anyone from receiving those events.
It's not censorship in itself but it would promote a concentration of relays as those events could not flow between relays unless the relays themselves pushed them to other relays or agreed on some mirroring. Now if I always was part of this group chat and my relay gave me the boot, I would be excluded from the group. I would have to poke members to convince them to mirror the group on a different relay but only if all members agreed on the same other relay, the group could re-assemble.
I highly dislike the idea of relays not being redundant to begin with.
We are perfectly fine joining subreddits, IRC channels, Telegram channels and groups (even Twitter has chat groups).
Subreddits is a great example! I can lurk them without subscribing to them. I think IRC works the same. Telegram public groups also allow having a look inside before joining. None of that requires relays to block mirroring.
There is no need for group-chat to happen on kind-1 or any other existing kind and nobody in their right mind would program a client for group chat and then show all group chats in once mixed stream. All clients for the purpose of group-chatting would filter by the desired groups. And for spam issues you need to decide who you want to listen to and who not anyway.
Would this work as new kind or with existing kinds? Someone who does a like (kind7) on a multicast, does it work the same? I'm starting to understand better the cases where this would make sense, this becomes a chat group essentially. To see the group messages, you need to subscribe to it.
— Tiago Balas
On 17 Aug 2022, at 17:47, Ricardo Arturo Cabral Mejía @.***> wrote:
https://en.m.wikipedia.org/wiki/Multicast
I think the difference is that on nostr, relays don't broadcast, it's always unicast based on requests(no?), and with this, what I see is people missing conversations because they didn't know they'd need to subscribe, they'll fail to receive these events, even though they subscribed the pubkey. Maybe like you said, I'll understand better with more examples but I'm not seeing it as is.
With this NIP we are taking the Multicast concept for network packets and applying it to nostr events.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.