Let's go!! Wanna chat? https://cordn.net/p/besao
View quoted note →
Besao
besao@cordn.net
npub1qc8q...twss
Cooking 🍳
Wanna chat? https://cordn.net/p/besao
Boom! This is out! Fresh out of the oven. Publishing on @Zapstore has been a breeze so far.
View quoted note →
The Android app is coming out very soon 🔥🔥🔥 and in honor of that, we’ve created the official Cordn account. So far, we’ve been managing everything through this profile, but it’s time to move forward. Follow it for news and stay up to date about what’s coming for truly private messaging over Nostr.
View quoted note →
Multiple Media Uploads: Send a whole batch at once. 📎
Some users requested the ability to upload multiple files at once, previously, you could only send one at a time. Now, you can select multiple photos or files and send them together. You’ll also see real-time progress, so you’ll know when a large file is being transferred, and you can cancel the upload with one tap if you change your mind. As always, everything remains end-to-end encrypted.
And for Android users waiting in the wings: a native Cordn app is just around the corner. 👀
We’re already working on the native Cordn app for Android. This feels like the next logical step after the multi-device release we recently launched. It’s already shaping up well, we have a very alpha version in internal testing, with native notifications working without third-party push notification servers or anything similar. It’s very private and efficient, with good battery performance so far. This is going to be lit!🔥🔥🔥
We’ll likely have a solid version ready by next week, which we will release on @Zapstore Looking forward to it!
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.
View quoted note →
If you want to use it, go to Config > Multi-device and click the Sync & Generate button. Then, open Cordn on another device, log in with your account, and scan or paste the generated string. From there, you don’t need to worry about anything else.
View quoted note →
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
Private group messaging you can own. Contribute to Cordn-msg/cordn development by creating an account on GitHub.
GM nostr! Today we'll release multi device feature, and it will be smooth af, automatic sync between devices, 0 babysiting. Stay tuned 🚀
Quietly working on the next big leap for Cordn. Stay tuned, lads.
New cordn coordinator 0.4.0 is here!
This release completes the rollout of sealed message delivery, every group message is now sent sealed by default, so hardened group privacy delivery is the standard rather than an opt-in. It was already since a couple of weeks ago, now all the legacy code in the coordinator have been removed.
We also fixed a bug where the streams that push messages out to clients (our writers) could keep running after a client disappeared without a clean goodbye. Left unchecked, those leftovers would gradually slow the server down over days of use. Writers now notice silent drop-offs and clean up on their own.
Thanks to everyone who's been testing along the way keep the feedback coming!
Great pod! Also, Cordn received a shoutout here. Really appreciate it! 🎇 We will continue building, so hopefully more people and merchants can have a great experience with private comms over Nostr
View quoted note →