main obstacle to a practical implementation of DMs on a network of intermediaries like nostr relays is not really any different from any other thing. you can do MLS using ephemeral events, as one way, though it has scale limitations, the way that doesn't is where relays enforce privilege to restrict reading private events to authed users.
i have been hammering at this last point for the last 2 years but nobody seems to listen to me. fortunately, my relay implements it and there is a growing number of users who have in mind private network deployments that can also be easily bridged to open public access as well as respecting the confidentiality of the operators of this network.
the liveness problem of private communication for methods like MLS make it a lot more challenging than it would be with a dedicated protocol, and i just think that the lack of DM support is the number one thing retarding nostr adoption.
Replies (3)
Nostr was never conceptualised for DMs. If you trust the concept for something then use it for what it was conceptualised for.
DMs add a need for assured delivery that wasn't there before
DMs add a need for encryption that wasn't there before
Encryption adds a need for derived identities that wasn't there before
Encryption adds a need for nsec hygiene that wasn't there before
Nsec hygiene adds a need for remote signing that wasn't there before
DMs add a need for relay specialisation that wasn't there before
Relay specialisation adds a client UIs that wasn't there before
The list goes on and on.
DMs are a trojan horse, let them in and soon the city gates are open for an horde of barbaric complexity to march through.
What are you talking about?
Nostr had dms very early on, and is incredibly useful for things like a marketplace where customers need to dm merchants.
Your being a technocrat
I am so pleased to read this from one of the original designers of the protocol.
