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:
We wrote it to be read.
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: GitHub
cordn/spec/applications/multi-device.md at master · Cordn-msg/cordn
Contribute to Cordn-msg/cordn development by creating an account on GitHub.