Is White Noise going to represent a protocol then? Like in the Blossom sense?
This why I’m spending so much time getting nostr:npub1whtn0s68y3cs98zysa4nxrfzss5g5snhndv35tk5m2sudsr7ltms48r3ec and MLS messaging on nostr right.
It can’t just be an app. It had to be an unassailable and unstoppable protocol.
They will come. And when they do, there can’t be anything they can do.
Discussion
It already does. https://github.com/nostr-protocol/nips/pull/1427
Means NIP-EE is intended to be seen as not just a NIP but a protocol (that'll be split out and have it's own separate NIP-like docs)? Keychat is not on NIP-EE, so that would make Keychat on another protocol? Or what's the wider lay of the land here?
So NIP-EE is all about how to apply the MLS protocol to Nostr. MLS is a true protocol but is agnostic in how implementations do message delivery and identity (the specifically call out that this is the domain of the implementations).
NIP-EE fills in the blanks for how to use Nostr for those two services. It's probably won't have it's own NIPs per se, but maybe it should given the overall complexity of MLS messaging and the additional protocol features we'll want to add over time.
Keychat is off spec and won't be interoperable until they change. But many other apps will be implementing NIP-EE messaging so we'll have interoperable uses of MLS all over nostr soon.