Cordn doesn’t have any funding, no VC money, no grants, like other projects do. Cordn doesn’t have a big team, nor an organization or a director behind it. We’re building Cordn as a service for the community and for ourselves because we believe that truly private, permissionless, secure, and accessible communications is a fundamental human right that we must defend in these darker times.
We’re pushing as hard as we can to make this a reality, so you don’t have to bend over when things get darker. In short, to be free.
This is a grassroots movement, and the people building it are doing so for the sake of making this a reality, to have a real alternative, totally voluntarily. This is a community project. So, if you like what we’re building, please consider contributing in any way you can, whether by testing, providing feedback, creating content, or sending us some zaps. Everything is welcome and helps us keep pushing and growing this.
Multi-device is here 💻📱💻
There's an expectation so basic it barely feels worth saying: if you join a group on your laptop, it should be on your phone too. Your account, your groups, on whatever device you're holding.
Until now, Cordn couldn't do that, and getting there took real engineering (and almost 2 weeks of work). This is one of the largest changes Cordn has shipped, because the obvious-sounding behavior required a genuinely non-obvious design.
The hard part is that MLS, the encryption protocol Cordn groups run on, doesn't hand you multi-device for free. There are two honest ways to add a device, and they pull in opposite directions.
The way the standard envisions makes each device its own member of the group, with its own keys and its own state. That's a legitimate model with real virtues: you can revoke a single device, and one compromised device doesn't compromise the others. It also has real costs: adding a device means an explicit invite every time, if you join a group you need to invite all your devices, and the group's membership structure reveals how many devices you run. In practice, people who wanted multi-device today were already doing a rough version of this by hand. They'd create a second account on the new device and add it to the group as a separate member.
We went the other way. Your devices share one identity inside every group. One set of keys, one membership, the same state replicated across all of them. Link a device once with a connection string, and from then on:
- A group you join or create on one device appears on the others, automatically.
- Remove a group from your list, and it's gone everywhere.
- Nothing to invite, nothing to babysit.
Because every device is the same member, the group can't tell how many you're running either, so your hardware footprint stays yours.
Under the hood this required solving a stack of genuinely hard problems: how devices reconcile state, how offline catch-up recovers messages without losing them, how deletions stick across the fleet, what happens when two devices act at once. The good news is you don't have to think about any of it. Turn on sync, link your devices, and the complexity stays out of sight.
This isn't free, and we want to be straight about the trade. Sharing the same state across devices means we give up per-device security. But the catastrophic case is losing your account key and your connection string together, but even then MLS's forward secrecy and post-compromise security still hold, rekeying/rotating the string recovers you, and no one else in your groups is affected.
Importantly, this doesn't replace the standard approach. It's an alternative, and both are legitimate. The RFC's per-device model gives you security properties ours trades away; ours gives you seamless sync and a hidden device count it structurally can't. Multi-device is entirely opt-in: nothing changes unless you explicitly turn it on and link devices. If you prefer the manual, per-device way, you can keep right on doing it. Nothing is forced on you.
We worked hard to catch the edge cases, and it's mature enough to depend on. But it's new, so treat it as experimental, and if you hit a bug, tell us.
The full design (every decision, every tradeoff, every invariant) is in the spec: https://github.com/Cordn-msg/cordn/blob/master/spec/applications/multi-device.md
We wrote it to be read.
View quoted note →
There's an expectation so basic it barely feels worth saying: if you join a group on your laptop, it should be on your phone too. Your account, your groups, on whatever device you're holding.
Until now, Cordn couldn't do that, and getting there took real engineering (and almost 2 weeks of work). This is one of the largest changes Cordn has shipped, because the obvious-sounding behavior required a genuinely non-obvious design.
The hard part is that MLS, the encryption protocol Cordn groups run on, doesn't hand you multi-device for free. There are two honest ways to add a device, and they pull in opposite directions.
The way the standard envisions makes each device its own member of the group, with its own keys and its own state. That's a legitimate model with real virtues: you can revoke a single device, and one compromised device doesn't compromise the others. It also has real costs: adding a device means an explicit invite every time, if you join a group you need to invite all your devices, and the group's membership structure reveals how many devices you run. In practice, people who wanted multi-device today were already doing a rough version of this by hand. They'd create a second account on the new device and add it to the group as a separate member.
We went the other way. Your devices share one identity inside every group. One set of keys, one membership, the same state replicated across all of them. Link a device once with a connection string, and from then on:
- A group you join or create on one device appears on the others, automatically.
- Remove a group from your list, and it's gone everywhere.
- Nothing to invite, nothing to babysit.
Because every device is the same member, the group can't tell how many you're running either, so your hardware footprint stays yours.
Under the hood this required solving a stack of genuinely hard problems: how devices reconcile state, how offline catch-up recovers messages without losing them, how deletions stick across the fleet, what happens when two devices act at once. The good news is you don't have to think about any of it. Turn on sync, link your devices, and the complexity stays out of sight.
This isn't free, and we want to be straight about the trade. Sharing the same state across devices means we give up per-device security. But the catastrophic case is losing your account key and your connection string together, but even then MLS's forward secrecy and post-compromise security still hold, rekeying/rotating the string recovers you, and no one else in your groups is affected.
Importantly, this doesn't replace the standard approach. It's an alternative, and both are legitimate. The RFC's per-device model gives you security properties ours trades away; ours gives you seamless sync and a hidden device count it structurally can't. Multi-device is entirely opt-in: nothing changes unless you explicitly turn it on and link devices. If you prefer the manual, per-device way, you can keep right on doing it. Nothing is forced on you.
We worked hard to catch the edge cases, and it's mature enough to depend on. But it's new, so treat it as experimental, and if you hit a bug, tell us.
The full design (every decision, every tradeoff, every invariant) is in the spec: https://github.com/Cordn-msg/cordn/blob/master/spec/applications/multi-device.md
We wrote it to be read.