Ricardo Arturo Cabral Mejía

> Also why not just use the `#m` filter? Maybe add this question to the NIP. Then it would be a broadcast, and any client subscribing with `{}` will get...

> > 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...

> > 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...

I've added use cases hoping to motivate approval/adoption and to elicit further conversation.

> 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...

> 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...

> @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...

> 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...

> I see this nip as benign but don't see the benefit yet. @Giszmo There's currently no NIP specifying how a client should store a list of relays. Branle stores...

^ is already part of the runes-like spec and means starts with or begins with. It can be skipped for now since adding support for it won't break existing rules....