A little while ago (in May) @Besao released an encrypted messaging protocol called Cordn (#1496327).
My understanding is that it allows you to do multiparty end-to-end encrypted communication but requires a coordinator. At the time of Besao's post, it sounded like Cordn was running a coordinator -- although they had published their code so anyone conceivably could do it.
And that seems to be what happened...but not as was expected:
Today, I saw Gzuuus post about an ephemeral coordinator on nostr:
Here is Cordn Ad-Hoc:
It looks like a temporary coordinator that vanished as soon as your browser tab is closed. It was created by a sandwich and looks pretty cool (to my totally naive eyes -- I do not know a thing about cryptography).
Cordn Ad-Hoc is a
Web-based MLS coordinator for ad-hoc Cordn groups. The app runs a ContextVM/Nostr coordinator in a browser tab, publishes its coordinator pubkey, and lets Cordn clients use that browser tab as the group coordination server.
Here's how sandwich describes what it does:
- Runs the Cordn coordinator protocol from a browser.
- Receives ContextVM MCP requests over Nostr relays.
- Stores MLS key packages, welcomes, join requests, and group messages locally.
- Supports streaming group-message subscriptions.
- Persists relay/runtime configuration in browser storage.
- Optionally encrypts and persists the coordinator identity behind a passphrase.
- Prevents multiple coordinators with the same pubkey from running at once.
- Exposes an operator debug log for raw Nostr events, decoded requests, responses, relay publish state, and instance heartbeats.
Hey! I'm the main developer behind Cordn.
Exactly, Cordn uses MLS for encryption and security, which is now standard on the internet. It ensures forward secrecy and post-compromise security, and it's future-proof since it's not tied to a specific cipher suite. You could even run your group on post-quantum crypto if you wanted. What made me choose MLS in the first place was its ability to scale for pretty large groups, unlike Double Ratchet (Signal). Also, in MLS, all user secrets are kept client-side, so coordinators can indeed stay "dumb" (like good ol' Nostr relays) and can't learn anything useful from the traffic they receive and route. In other words, a group can survive a bad coordinator.
It's true that a coordinator could run malicious targeted attacks (as any Nostr relay could), but this is very unlikely, and the harm is contained. We're working to make this even harder for coordinators. Also, in a very adversarial situation, the idea is that deploying a coordinator is easy and doesn't require touching IPs, DNS, firewalls, or anything like that to expose it, as Sandwich beautifully demonstrated with the ad-hoc coordinator.
Indeed, yesterday @gzuuus published an update to his article "Private comms over public infra," adding three new protocols he analyzed. Cordn is among them, along with Concord and Nymchat. He did a really good analysis, highly recommended to read it to understand how this works.
Anyway, enough prose. Thanks for the interest, and happy to keep discussing here or on Cordn :) https://cordn.net/p/npub1qc8quy6ah46k4q9es6fvjqjgk6rdv42cdsccnjhyx59j35n7azlq7ntwss