Hey nostr, do you want private communications?

Testing this is as easy as: 1. Open https://cordn.net/chat 2. Log in and follow the recommended setup; it will add the default coordinator we are running and create a key package. 3. Start chatting. If you’d like to be added to the Cordn Dev chat, please let me know and I can add you.

🔥Today is the day 🔥 I’m excited to introduce Cordn (https://cordn.net). This is my take on private, accessible communication for everyone. Cordn is a small protocol built on two solid foundations: and MLS. MLS is already emerging as an internet standard, and it handles the cryptographic heavy lifting. It provides quite strong security guarantees, including post-compromise forward and backward secrecy. It is also highly scalable, handling large groups efficiently without the overhead that double-ratchet protocols like Signal carry. That power comes with a requirement. MLS needs tight coordination between group members. All the secrets that let you participate are computed locally, and without strict message ordering, an out-of-order message can cause your state to drift. You could silently fork yourself out of a group without ever noticing. That is exactly why Cordn is built around the concept of coordinators, or delivery services, as the MLS specification calls them. A coordinator have very little responsability: it keeps messages in order. It cannot see who is participating. It cannot read messages. It cannot see IP addresses. It just orders messages and delivers them. Cordn uses one coordinator per group. This keeps state simple and avoids the consistency problems and race conditions that come from splitting a group across multiple coordinators. The upside is that Cordn is fully open source, and deploying your own coordinator is effortless. Switching between coordinators is straightforward too, thanks to ContextVM. You can run a coordinator behind a firewall or NAT. No static IP, no domain, no DNS required. Just run the existing coordinator implementation on any device and it becomes accessible. Using ContextVM was a deliberate choice. It makes deployment trivial, and it strengthens privacy because Cordn traffic is fully encrypted and blends into broader ContextVM traffic. An external observer learns nothing useful. They cannot tell that Cordn is being used, let alone who is using it or which groups exist. Running your coordinator would be the equivalent of running a Discord server or a Signal server, but in a very easy way, fully private and open source. Coordinators handle three things: message ordering, storing and delivering encrypted blobs, and acting as a key package directory. That's it. Spinning one up takes a single command: 'docker run --rm ghcr.io/cordn-msg/cordn:latest' Because coordinators are intentionally minimal, migrating between them is clean. If your group’s coordinator goes offline, you can move to another one and carry on. The rule is simple: one coordinator per group at a time. Migration is not fully implemented yet, but it is coming soon, along with multi-device support. Today I am announcing both the coordinator and a web client, now live at https://cordn.net. There is also a CLI client available in the main repo; it is primarily intended for testing, but it is fully usable and interoperable with the web client. The web client is already quite capable. It is early, and there are still rough edges, but the experience is quite solid. I spent the weekend stress-testing it with groups of around ten people, plus smaller groups and individual chats. It held up well, which gives me the confidence to release it. Cordn is also a protocol. It draws inspiration from around user identities, group metadata, and Nostr envelopes for group messages. Kudos to the Marmot team for pushing boundaries. The protocol defines coordinator roles, transport conventions, group metadata, identity conventions, and Nostr message envelopes. If you are curious and want to build on it, the spec and code are at https://github.com/Cordn-msg/cordn. There is also a larger text about the why behind Cordn at https://cordn.net/why if you are einterested. That is Cordn in a nutshell: private messaging you can own, sovereign, and accessible to everyone. To lower the barrier to entry, we are running a public coordinator so you can get started without hosting anything yourself. It is completely free and will stay that way until everything is stable. After that, we will figure out how to pay the bills. The important part is that a fully sovereign experience is always available. You can run your own coordinator for yourself, you agent swarm, your friends, your family, or your community, you own it. We are running ours on an inexpensive VPS from , and you can easily do the same. We also plan to release deployments for Umbrel and Start9 soon. If you have experience packaging apps for those platforms, your help would be deeply appreciated. Cordn is fully open source, and every contribution matters. We are building this for love and freedom. I cannot close without thanking and the team. They provided the inspiration and the core technology that made Cordn possible. It began with a ContextVM project called cvm-mls, which planted the seed for everything here. gz also opened my eyes with his article “Private communications, over public infrastructure” and pointed me to the cvm-mls repo. None of this would exist without them. Thank you so much. Without further ado, you can reach me here on Nostr and, of course, on Cordn. Do not hesitate to ask anything. We also have a Cordn dev group you are totally invited to join, so let me know and we will add you. Reference RFC9420: https://datatracker.ietf.org/doc/rfc9420/

Hehe wait for it! will be out soon

Now or never

👋

Tomorrow 🎇

MLS is well suited for large groups. Marmot uses MLS, but that doesn’t mean it scales in the same way, since some of the protocol’s conventions are shifted. Specifically, MLS requires strong coordination among all group members. This means that things like out-of-order messages, degraded network states, and similar issues break MLS. That’s why MLS deployments typically require a coordinator or delivery service to ensure group messages follow the strict ordering MLS demands. Marmot, however, uses Nostr relays as both a dissemination layer and storage. Since there’s no delivery service or nothing ensuring that all members receive messages in the same order, all the coordination MLS requires must be handled client-side by each participant. Each participant must reach the same state to maintain group integrity. This means the complexity of keeping everyone on the same page scales with the group size. For example, a group of two usually works without issues. A group of three requires that each member consistently lands in the same state, which is manageable under good hygiene and network conditions, meaning all relays in a set are online at all times, with no race conditions (e.g., one relay going offline while others don’t, you know classic nostr race conditions). But still three members can work under good conditions. But as you add more people, each new member increases the complexity of keeping everyone synchronized. Anyway, sorry for the length 😅 I tried to explain myself as clearly as possible. But in summary, MLS scales well for large groups but requires coordination. Without coordination, these scalability assumptions break down. I reached these conclusions after reading ’s article on private communications over public infrastructure, as well as discussions with him. It was very helpful indeed I hope this clarifies things! Please don’t hesitate to ask if you have any questions, these are complex technical details :)

Oh yes, Simplex has been a great reference, as well as Signal, but we finally went with MLS since it is indeed the most portable, open, and scalable solution from our point of view.

No, they have been a great inspiration, and we are reusing some of their concepts. However, the motivation to start this project was directly the frustration of making Marmot work for groups of more than two people

CC