Nostr notes by Besao

When you cannot find the words, say it with a GIF :) ...

2026-10-07T16:28:47Z

When you cannot find the words, say it with a GIF :)

quoting
nevent1q…9hdn
📱✨ New Cordn update: GIFs in the chat, big histories that stay smooth, and notifications that land on the news ✨📱

Cordn 0.5.5 is out! A release of expression and quiet speed: say it with a GIF, type and scroll without a stutter even in chats that go back forever, and a notification tap that puts you right where the new messages begin.

😂 Say it with a GIF: press the + next to the message box, choose GIF, and search the gallery — words in any language, or just an emoji like 😂. Tap one and it drops into your message, ready to send alone or with a caption, and plays right in the chat. They follow your media auto-load setting, so GIFs stay behind the "Load media" tap if you prefer it that way. (GIFs come from nostr.build — thank you for the free search API 💜)

🧈 Big chats, zero stutter: typing and scrolling stay smooth no matter how far back a chat goes — the more history behind it, the more you'll feel this one. Opening a long conversation is quicker too, with the app handling its message history far more efficiently behind the scenes. Same messages, same unread counts, just lighter.

🔔 Notifications land on the news: on Android, tapping a notification used to drop you at the very bottom and quietly mark everything read on the way. Now it opens the chat at the first unread message — exactly like opening it from the list.

@️⃣ Mentions that count everywhere: mentioning someone in the caption of a photo, video, or voice note finally works like a mention anywhere else — a proper @name chip that actually pings the person, instead of silently arriving as plain text. The reply and edit previews show @name too, not raw codes.

🎬 Calmer videos: tapping play or pause no longer pops the keyboard over the video, and scrubbing or long-pressing one no longer drags the message around or opens its menu by accident.

🪟 And a handshake: cordn.net group and profile links can now open in Staircase, the independent Android client for Cordn — if you have both installed, Android asks which one to use.

Already available in Zapstore and obtainium.

https://zapstore.dev/apps/org.cordn.app

🎁 The free @cordn.net names are still going out. Want one? Ask in the comments and we'll point it at your pubkey.

The full release notes live at https://cordn.net/chat/news

Aren't you using Cordn yet? Just start chatting at https://cordn.net/

If you like the project and want to see it grow, please consider contributing in any way you can. Every bit counts, report a bug, contribute with your expertise. We are building this together in the open 💛

Full changelog: https://github.com/Cordn-msg/cordn-web/releases/tag/v0.5.5

Trust me boy we won't stop #nevent1q…nnm5

2026-10-02T14:49:47Z

Trust me boy we won't stop

quoting
nevent1q…nnm5
📱✨ New Cordn update: reactions that live in the timeline, inline nostr embeds, and steadier linked devices ✨📱

Cordn 0.5.2 is out! A feelings-finally-expressed release: your reactions now have a home in the conversation, links and nostr events open right where you are, photos paste straight into the box, and linked devices that drift apart find their own way back.

❤ Reactions in the timeline: reactions now appear as small marker rows right in the message flow — you'll see who reacted and when, in context. You can remove your own reactions with one tap (and put them back just as easily), your own are visibly marked as yours, and if you find the rows noisy there's a setting to turn them off entirely.

🔗 The web where you're chatting: paste a nostr event link (note, article, profile…) into a chat and it unfolds into a proper card — real author names and avatars, readable text with a "show more" clamp instead of a wall of nothing. Link cards got the full polish pass: clear metadata, working article titles, external viewer buttons, a "⋯" menu — and on phones the layout finally breathes instead of overflowing. Prefer a clean chat? There's now an embeds on/off setting. And external links hand off to the in-app browser instead of kicking you out to the system one.

🖼 Paste, don't attach: on web and Android, just paste a screenshot or photo (Ctrl+V / long-press paste) and it lands in the message box — staged instantly with a visible processing state, ready to send.

📊 Tables that render: markdown pipe tables (GFM style) now render properly in messages — paste a table, get a table.

⚡ Linked devices that heal themselves: if your devices disagree after a bad sync, they now gather fork evidence, compare histories fairly, and converge on the right one — instead of stalling or duplicating. A device that falls behind schedules its own catch-up retries, and a whole class of false "unreachable coordinator" alarms that could hurt your healthy servers is gone.

🩹 And the paper cuts: the jump-to-unread-mention button sits beside the scroll-to-bottom button now, message-run avatars stay anchored to the newest message again, and a stray rendering artifact in message runs no longer shows up as text.

Already available in Zapstore and obtainium.

https://zapstore.dev/apps/org.cordn.app

🎁 The free @cordn.net names are still going out. Want one? Ask in the comments and we'll point it at your pubkey.

The full release notes live at https://cordn.net/chat/news

Aren't you using Cordn yet? Just start chatting at https://cordn.net/

If you like the project and want to see it grow, please consider contributing in any way you can. Every bit counts, report a bug, contribute with your expertise. We are building this together in the open 💛

Full changelog: https://github.com/Cordn-msg/cordn-web/releases/tag/v0.5.2

Nostr event nevent1qqszf2mte3xq9r6t6fdx7sed0c78y2ashvgqnj9ke4xczfm7wn9883gzyqrqursntk7h265qhxrf9jgzfzmgd4j4tpkrrzw2us6sk2xj0m5tuyffe23

2026-10-01T11:42:51Z

Sovereignty means not relying on infra controlled by others

Let's go! We keep evolving #nevent1q…p2lw

2026-09-29T15:03:54Z

Let's go! We keep evolving

quoting
nevent1q…p2lw
📱✨ New Cordn update: pinned chats, smoother chat, and loads of tiny improvements ✨📱

Cordn 0.5.1 is out! A tidy-things-up release: keep your favorite chats within reach, notifications that respect your attention, photos you can actually zoom, and a long list of paper cuts finally healed.

📌 Pin what matters: press and hold a chat on your phone (or open its "⋮" menu) to pin it to the top of your list. Pinned chats stay above everything else — your pins are yours alone, kept on your device.

🖱 Drop it like you mean it: on the web, drag files straight onto the chat window and they wait in the message box for review — send when you're ready.

🔔 Notifications that behave: a burst of messages in a busy group is now one notification — the newest with a "+N more" hint — instead of a flood. Reading a group clears its notification on the spot, leftovers from chats you've already read no longer linger, and your own messages (yes, the check marks) no longer badge their group as unread.

🖼 Photos at your fingertips: pinch to zoom, drag to pan, double-tap to jump between 1× and zoomed — the lightbox finally feels like one. On Android, downloads save through the proper system save dialog instead of popping a share sheet.

💬 Previews that say what arrived: group cards and notifications now show "📷 Photo", "📎 file.pdf", "🎤 Voice message" or who just joined — with real profile names — instead of falling back to "Group chat".

📖 Land where you left off: opening a chat drops you right at the first unread message, clearly marked — even in histories thousands of messages long.

⚡ Steadier when the world isn't: one unreachable server can no longer slow down your other chats or delay your sends. Renames and invites made right as a connection dropped now reach your linked devices on their own. Groups on self-hosted coordinators connect directly and immediately instead of falling back to the public defaults. And under the hood it's smoother: avatars no longer flash or re-fade when you open a group or a message arrives, replies survive photo captions, and a rare crash on some group info pages now heals itself.

Already available in Zapstore and obtainium.

https://zapstore.dev/apps/org.cordn.app

🎁 The free @cordn.net names are still going out. Want one? Ask in the comments and we'll point it at your pubkey.

The full release notes live at https://cordn.net/chat/news

Aren't you using Cordn yet? Just start chatting at https://cordn.net/

If you like the project and want to see it grow, please consider contributing in any way you can. Every bit counts, report a bug, contribute with your expertise. We are building this together in the open 💛

Full changelog: https://github.com/Cordn-msg/cordn-web/releases/tag/v0.5.1

LFG! Themes are awesome #nevent1q…z4cm

2026-09-22T14:21:01Z

LFG! Themes are awesome

quoting
nevent1q…z4cm
📱✨ New Cordn update: themes are here, improved UX, and loads of small things ✨📱

Cordn 0.5.0 is out! And for the first time, your chats can look the way you like. Pick a theme, or build your own. We also taught messages to render markdown, and smoothed out a pile of little things along the way.

🎨 Make it yours: Settings now has a whole Appearance section with eight built-in themes, from calm Soft to terminal Matrix, warm paper tones to a deep purple Ostrich. Want your own? Fork any theme and tweak every color and corner radius with a live preview, edit it as JSON and share it around — or hit Roll and let chance pick one for you. Either way it stays readable, guaranteed.

✍ Messages look like you meant them: bold, italic, code, lists and links now render right in chat — what you write is what they read.

📨 Write now, send whenever: messages sent offline wait their turn and go out the moment you reconnect — exactly once. A flaky connection can never deliver the same message twice.

📸 Photos leave no fingerprints: every photo is stripped of its metadata — where it was taken, what took it — before it ever leaves your device. HEIC images also convert to something everyone can open.

🎛 The little things, all fixed up: Enter now behaves the way you expect — it sends on desktop and starts a new line on mobile, and you can change it in Settings. Voice notes need a deliberate hold to arm, so a stray swipe can't grab your mic. No more buzzing for notifications while the app is open in front of you, no more messages jumping around as they settle in.

⚡ Under the hood it's quicker and steadier: long chats stay smooth even at thousands of messages, errors name the right coordinator when one fails, and signers that can't support NIP-44 v2 tell you up front. Coordinators now show real names from nostr profiles and share with one tap.

Already available in Zapstore and obtainium.

https://zapstore.dev/apps/org.cordn.app

🎁 The free @cordn.net names are still going out. Want one? Ask in the comments and we'll point it at your pubkey.

The full release notes live at https://cordn.net/chat/news

Aren't you using Cordn yet? Just start chatting at https://cordn.net/

If you like the project and want to see it grow, please consider contributing in any way you can. Every bit counts, report a bug, contribute with your expertisats. We are building this together in the open 💛

Full changelog: https://github.com/Cordn-msg/cordn-web/releases/tag/v0.5.0

You have it! cordn.net/p/ngmi also you can use the nip05 ...

2026-09-11T19:01:06Z

In reply to nevent1q…3gdp
_________________________

You have it! cordn.net/p/ngmi also you can use the nip05 ngmi@cordn.net

What name, ngmi?

2026-09-11T16:32:22Z

In reply to nevent1q…mram
_________________________

What name, ngmi?

Hahaha too good not to use it

2026-09-11T09:57:31Z

In reply to nevent1q…yrgu
_________________________

Hahaha too good not to use it

Bring love 🫶 Thanks!

2026-08-29T16:27:37Z

In reply to nevent1q…z3vp
_________________________

Bring love 🫶 Thanks!

Nostr event nevent1qqspkrghl2tp7w6l0ue0u6vdk4uqhq6qnkaq8p7t0yc0kjgj82n8mpgzyqrqursntk7h265qhxrf9jgzfzmgd4j4tpkrrzw2us6sk2xj0m5tus0sush

2026-08-29T14:25:33Z

quoting
nevent1q…y45e
The coordinator is in the phone!

What if the server hosting your private group chats was just… your phone? We just made it possible. Install the Cordn Coordinator app, press Start, and even an old Android phone lying on your desk becomes the heart of your groups. No VPS, no 20-step tutorial, just an APK.

This is sovereignty no other messaging service offers. With Cordn, the entire delivery coordinator runs on a device you own: no company that can shut you down, no server you don't control. If you rely on someone else's infrastructure, you are not sovereign.

It's the same open-source Rust coordinator (cordn-rs), packaged as an Android app:

🔌 One button. It runs as a foreground service in its own process. Close the app, ignore the phone, your groups keep being served.

🔐 Infra you own. The Nostr identity is generated on-device, its private key sealed in the Android Keystore, the data in app-private storage.

🔗 Easy to share. Show the QR or the cordn.net link, and your friends' Cordn clients add your coordinator in one scan.

♻ An old phone is perfect hardware: screen, battery, wifi. Give it a second life as the most private comms server in your house.

Free and open source (MIT):
📲 Zapstore: https://zapstore.dev/apps/org.cordn.coordinator
💻 GitHub: https://github.com/Cordn-msg/cordn-rs (signed APKs on Releases)

Set it up in under a minute and host your own corner of Cordn.

Like the project? Contribute any way you can: report a bug, share feedback, send some sats. We're building this together in the open 💛

Wooop woop!! #nevent1q…a55g

2026-08-18T17:56:01Z

Wooop woop!!

quoting
nevent1q…a55g
🎤🔥 New Cordn update: voice notes 🔥🎤

Sometimes you'd rather talk than type. Now you can: hold the mic button to record a voice note, release to send. Drag up to record hands-free, drag left to cancel. Voice notes play right in the conversation with a seekable waveform and timer, and like everything in Cordn, they're end-to-end encrypted and private.

Already available in Zapstore and obtanium.

That's the headline of 0.3.0, but there's more:

🎨 A full UI/UX refresh across the whole chat app: a calmer chat home with clear tiles for starting a chat, checking notifications, and settings, a simple most-recent-first sidebar, and plain words throughout (Config is now Settings, welcomes are invitations). Pull-to-refresh on the chat list, too.

🔗 Portable group links: the new cordn1 format packs the coordinator and relay hints right into the link, so an invite opens correctly no matter which Cordn client or setup receives it, and pasting one into a chat opens the group in-app.

⚡ Creating a group with several people is much faster: everyone is added in a single batch instead of one invite round per person.

📷 On native Android: take photos and record videos straight from the composer, a back button that behaves like you'd expect, edge-to-edge screens, a keyboard that never covers the composer, and fixes for the crash after a phone restart and when saving backups.

🐛 Under the hood: messages from a linked device no longer fail to decrypt, chat connections recover steadier and quieter, zombie key packages are gone from your settings, and other bug fixes.

🎁 The free @cordn.net names are still going out. Want one? Ask in the comments and we'll point it at your pubkey.

The full release notes live at https://cordn.net/chat/news

Aren't you using Cordn yet? Just start chatting at https://cordn.net/

If you like the project and want to see it grow, please consider contributing in any way you can. Every bit counts, report a bug, contribute with your expertise, send some sats. We are building this together in the open 💛

Yes, Cordn is designed the way it is to allow exactly this: a ...

2026-08-11T15:59:38Z

In reply to nevent1q…l7qv
_________________________

Yes, Cordn is designed the way it is to allow exactly this: a leader or preferred coordinator per group that keeps everything in order and avoids races that might occur when multiple sources have competing or out‑of‑order commits. It isn’t implemented yet, but it will be, we haven’t put much work into it so far because it’s an advanced feature that only power users will need, and we wanted to polish the UI/UX first. It will definitely come. But make it work reliable and have a good UX semeed what users request the most

Thanks guys!

2026-08-10T17:44:57Z

In reply to nevent1q…rtwf
_________________________

Thanks guys!

Thanks :) so do you want one?

2026-08-06T16:15:15Z

In reply to nevent1q…25ev
_________________________

Thanks :) so do you want one?

It is just a nip05 at cordn.net. Anyone can already just use ...

2026-08-05T11:02:37Z

In reply to nevent1q…93lr
_________________________

It is just a nip05 at cordn.net. Anyone can already just use their nip05 (e.g https://cordn.net/p/lez@nostr.hu ) but if you have one at cordn.net or the host where the app is living it will try to resolve from the host domain, that's why you can have a name without the nip05 domain part

Who wants a Cordn name like https://cordn.net/p/besao ? So you ...

2026-08-05T09:08:37Z

Who wants a Cordn name like https://cordn.net/p/besao ? So you can easily share it with people and start chatting 🔑

Yo guys, exciting news. We ported the Cordn coordinator to rust. ...

2026-07-27T16:44:18Z

Yo guys, exciting news. We ported the Cordn coordinator to rust. Now it is easier to run than ever, lighter, much more efficient, it can run in arm64 too, so you can just grab your pi be up in seconds. Hope you enjoy :)

quoting
nevent1q…qmh0
🦀 The Cordn coordinator, now native in Rust.

It's here: `cordn-rs`, the `cordn` MLS delivery coordinator you know, ported to Rust. Same protocol, same behavior, but dramatically faster and lighter.

The numbers say it all (measured head-to-head with the TypeScript original):
- 💤 ~35× less memory at idle — and still ~5× less under a full load.
- ⚡ Snappier responses, no spikes when it gets busy.
- 📦 One ~10 MB binary. Just drop it in.

The best part? It's a real drop-in. Your existing database opens and runs as-is. Swap the binary, keep your data, keep your clients.

Same version, same soul. `cordn-rs` moves in lockstep with `cordn`, same release, same number, no second versioning scheme to learn.

Try it in seconds:

```bash
curl -fsSL https://github.com/Cordn-msg/cordn-rs/raw/refs/heads/master/scripts/install.sh | sh
```

...or pull the Docker image:
```bash
docker run ghcr.io/cordn-msg/cordn-rs/cordn-server:latest
```

→ Repo, docs & benchmarks: https://github.com/Cordn-msg/cordn-rs

The same coordinator, lighter than ever. 🛰 This is our commitment with the project we are building, real production grade products that are easy to run anywhere.

Aren't you using Cordn yet? Just start chatting at cordn.net

If you like the project and want to see it grow, please consider contributing in any way you can. Every bit counts, report a bug, contribute with your expertise, send some sats. We are building this together in the open 💛

Thank you guys!

2026-07-27T11:05:01Z

In reply to nevent1q…ec3x
_________________________

Thank you guys!

Great article! really interesting

2026-07-26T21:34:15Z

In reply to nevent1q…nyqr
_________________________

Great article! really interesting

Let's go!! Wanna chat? https://cordn.net/p/besao ...

2026-07-24T17:18:33Z

Let's go!! Wanna chat? https://cordn.net/p/besao

quoting
nevent1q…k73v
🔥 New Cordn update: Cordn names and friendly links 🔥

Every Cordn profile page now has a human-readable address. Instead of a long npub, you can open a profile with a NIP-05 handle, any NIP-05, from any provider, right alongside hex, npub, and nprofile as before.

For cordn.net addresses specifically, the domain is optional: so NIP-05s like besao@cordn.net , your profile link would be simply http://cordn.net/p/besao . A clean handle you can put in a bio or drop in a DM.

🎁 Side note: if you'd like a @cordn.net name of your own, we're handing them out for free during a limited period of time, just ask in the comments and we'll point it at your pubkey.

This update (0.2.4) also ships with a few more things:

📷 On native Android, the in-app camera scanner works again for scanning group and coordinator QR codes, along with saving and sharing files, copying to the clipboard, and opening links externally.
👋 New accounts get a "Join Cordn group" button on chat home, so you can hop straight into the official discussion group. Thanks @laser for the idea
🔄 Inviting people to a new group no longer fails entirely if one key package is unreachable, each invite goes out on its own, and anything that fails surfaces as a toast.
🐛 Reloading a group right after inviting someone no longer drops the invite: pending add-member ops are now saved and reapplied on the next open.
🚚 A new migration banner: if you sign in and your account or key packages seem to live on another device, it links you straight to Backup & recovery to link your devices or restore from a backup.

The full release notes live at https://cordn.net/chat/news

Aren't you using Cordn yet? Just start chatting at https://cordn.net/

If you like the project and want to see it grow, please consider contributing in any way you can. Every bit counts, report a bug, contribute with your expertise, send some sats. We are building this together in the open 💛

Indeed. Will ship this in the next patch

2026-07-24T15:16:01Z

In reply to nevent1q…9fz5
_________________________

Indeed. Will ship this in the next patch

Yes, MLS is very complex to implement in a ...

2026-07-23T22:25:18Z

In reply to nevent1q…fahr
_________________________

Yes, MLS is very complex to implement in a "decentralized" way. The bet we’re making is to make coordinators very easy to run and switch, just one at a time to avoid out of order messages, that’s the rule. For example, sandwich (npub1uac…99rx) made a coordinator that can run in a browser tab, and it worked reasonably well even in its early version.nostr:nevent1qvzqqqqqqypzpem34u9stj8ftlxldl4n2qz5f5hmrnxns3uga86fpwe7u28ga4n0qyt8wumn8ghj7un9d3shjtnwdaehgu3wdejhgtcppemhxue69uhkummn9ekx7mp0qqsg6ds6tqc835edzght9yzapy3gh3vqtr849ud58ftzwc3kdv63c5gupgwkn

It is MLS, just transported differently. It uses coordinators, ...

2026-07-23T22:13:58Z

In reply to nevent1q…sua9
_________________________

It is MLS, just transported differently. It uses coordinators, which are just as dumb, or even dumber than, relays these days, for the ordering of messages (MLS requires strong ordering, which is why Marmot struggles so hard to work properly). Nostr relays transport messages between coordinators and clients using CVM, so everything is ephemeral on relays. It uses Nostr keys for identities, just like Marmot.

Cordn and Marmot are not compatible (though they could be), since MLS is such a complex protocol. Given their different requirements, they would need to agree on certain parts that they currently don’t. Happy to keep clearing doubts any time. The Gzuuus (npub1gzu…a5ds) article explains this very accurately.

Sure

2026-07-23T22:08:24Z

In reply to nevent1q…pxjm
_________________________

Sure

I don't know why they hate us so much. Grassroots vs VC ...

2026-07-23T19:04:26Z

In reply to nevent1q…7l8w
_________________________

I don't know why they hate us so much. Grassroots vs VC backed I supposed :/

Why you guys hate us so much?

2026-07-23T19:03:42Z

In reply to nevent1q…l2g4
_________________________

Why you guys hate us so much?

@npub10xv…g437 @npub1m4n…c2jl @npub1l5s…gx9z ...

2026-07-23T17:41:42Z

In reply to nevent1q…fcsz
_________________________

EricFJ (npub10xv…g437) Laeserin (npub1m4n…c2jl) Silberengel (npub1l5s…gx9z) Bitcoin Sikho (npub1ncf…j87x)

Boom! This is out! Fresh out of the oven. Publishing on ...

2026-07-23T17:40:46Z

Boom! This is out! Fresh out of the oven. Publishing on Zapstore (npub10r8…t2p8) has been a breeze so far.

quoting
nevent1q…2z6n
🔥 Exciting news 🔥 Cordn native Android app is here 📱

The native Cordn app is now available on ZapStore. This has been a long-requested feature, and it is finally here for everyone. ✨

https://zapstore.dev/apps/naddr1qqxk7un89e3k7unydchxzursqyv8wumn8ghj7un9d3shjtn6v9c8xar0wfjjuer9wcpzps7xmxansh7cyl8ak3wexws73n8jjpd7xpr8z50dtl34dgg22f0fqvzqqqr7pv6zvfm6

The headline reason to install it: push notifications. You no longer have to keep a tab open or keep checking the app to stay on top of your groups.

For the nerds, here is how they actually work. There is no third-party push server and no notification service sitting in the middle. Everything runs on your phone through efficient coordinator fetching, so this is as private and secure as the rest of Cordn.

The app ships with two more cool things:

💎 Amber login, alongside every other login method Cordn already supports, so you can sign in with your preferred Nostr signer.
🔗 A share intent handler, so sharing a link, image, or piece of text straight into a Cordn group is now a single tap from anywhere on your phone.

Prefer the web or a PWA? Nothing changes. You can keep using Cordn in the browser or installed as a PWA exactly as before. The native app is an addition, not a replacement, and it is what finally unblocks reliable notifications, a real requirement these days to not lose a beat in your groups.

This is the first official release and the first milestone in Cordn's native evolution. We tried our best to iron out every bug and edge case, but this is software, so please report anything you find. Feature requests are welcome too.

The full release notes live at https://cordn.net/chat/news

Aren't you using Cordn yet? Just start chatting at https://cordn.net/

If you like the project and want to see it grow, please consider contributing in any way you can. Every bit counts, report a bug, contribute with your expertise, send some sats. We are building this together in the open 💛

The Android app is coming out very soon 🔥🔥🔥 and in honor ...

2026-07-23T16:37:58Z

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.

quoting
nevent1q…fue8
Hello nostr!

Multiple Media Uploads: Send a whole batch at once. 📎 Some ...

2026-07-23T10:14:21Z

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. 👀

Yes, but fyi android native app is around the corner, probably ...

2026-07-20T17:21:52Z

In reply to nevent1q…5rcc
_________________________

Yes, but fyi android native app is around the corner, probably this week or early next week, and it'll bundle nip 55 login with amber :)

No, we considered using Unified Push, but it has two important ...

2026-07-20T07:40:49Z

In reply to nevent1q…nve2
_________________________

No, we considered using Unified Push, but it has two important tradeoffs. Users would need to install a third-party app to receive notifications, and someone would also need to run a server for notifications. We explored modifying the coordinator to add notification capabilities, but that wasn’t acceptable because it would violate the "dumb coordinator" constraint. So, we opted for the most straightforward solution: a worker that fetches messages from the coordinator at a specific frequency.

This approach is quite efficient because it involves a single API call (no subscriptions), and it only wakes the radio periodically. By default, we set the interval to 5 minutes, but users can configure it to 1 or 10 minutes. There’s also another option that doesn’t require persistent notifications but runs on a ~15-minute interval, this is the most reliable and battery lightweight mode. The faster options can be terminated in some phones.

In our testing, we’ve found it to be quite reliable. Even at the fastest interval of 1 minute, battery performance remains good. So far, it sits next to a signal with similar battery drain.

We’re already working on the native Cordn app for Android. This ...

2026-07-19T13:25:15Z

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 (npub10r8…t2p8) Looking forward to it!

Join our cordn channel! ...

2026-07-18T13:50:21Z

Join our cordn channel! https://cordn.net/chat/dfa7475d-c9ef-46df-bf85-1f481fdcf2c4?m=eyJuYW1lIjoiQ29yZG4gRGV2IiwiaWNvbiI6IvCfqqIifQ

quoting
nevent1q…rcyu
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.

nevent1q…m6e3

And the spirit of things. We would like to keep pushing ...

2026-07-17T09:30:54Z

In reply to nevent1q…7vyf
_________________________

And the spirit of things. We would like to keep pushing organically. Let's see how it goes :)

Cordn doesn’t have any funding, no VC money, no grants, like ...

2026-07-17T09:10:21Z

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.

quoting
nevent1q…m6e3
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.

Good question. There are actually two ratchets in MLS and we ...

2026-07-16T18:38:34Z

In reply to nevent1q…raxw
_________________________

Good question. There are actually two ratchets in MLS and we handle them differently.

For application messages, we don't coordinate generation picks across devices. We let them race. The delivery stream carries the generation in the clear, so when one device sends at gen N, the other sees it and advances its own counter past N. Self-echoes we match by ciphertext bytes (not leaf index), so a device knows if a "self" message was its own send or a sibling's, and advances accordingly. For the rare case where two devices grab the same N in the same instant, the RFC 9420 reuse guard adds fresh randomness to the nonce so the key/nonce pair stays distinct. That guard exists in single-device MLS anyway, so we get it for free. No fighting, no extra sync.

Commits are the part that can't be shared over the stream. A Commit refreshes the leaf with new keys, and only the committer gets the private half. A sibling trying to ingest it would mark itself removed. So we detect sibling Commits (sender leaf index equals ours), skip them, and the committing device republishes its full state on Blossom for the others to fast-forward from.

App messages ride the stream because their keys are derivable from the shared epoch secret. Commits can't, because the new leaf keys only exist on the committer.

Yes! We think so. Please share any feedback if you test it. The ...

2026-07-16T15:53:20Z

In reply to nevent1q…tmgx
_________________________

Yes! We think so. Please share any feedback if you test it. The next things are the enhancements you proposed these past few days

They share the same leaf node. The cool part is totally opt-in, ...

2026-07-16T15:52:18Z

In reply to nevent1q…ya85
_________________________

They share the same leaf node. The cool part is totally opt-in, you can keep using the manual multi-leaf-node approach that the RFC provides, or use this one, which is basically a mesh sync using Blossom and Nostr relays. Everything is in the spec if you're interested :)

If you want to use it, go to Config > Multi-device and click ...

2026-07-16T15:29:41Z

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.

quoting
nevent1q…z3pt
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.

cc @npub10xv…g437 @npub1l5s…gx9z @npub1klk…x3vt

2026-07-16T15:25:59Z

In reply to nevent1q…kmnr
_________________________

cc EricFJ (npub10xv…g437) Silberengel (npub1l5s…gx9z) Max (npub1klk…x3vt)

Multi-device is here 💻📱💻 ...

2026-07-16T15:24:27Z

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.

Actually is less overhead. MLS (Cordn) uses a tree-based group ...

2026-07-16T14:36:25Z

In reply to nevent1q…zq4e
_________________________

Actually is less overhead. MLS (Cordn) uses a tree-based group key agreement called TreeKEM to manage group state. In a balanced tree, join/leave/rotation operations touch only O(log n) nodes, so very large groups can handle rekeys (including member bans and key rotations) much more efficiently than protocols that re-encrypt or re-establish keys for all n members, such as Double Ratchet–based or naive custom group protocols, which are O(n) per rekey.

GM!

2026-07-16T14:10:42Z

In reply to nevent1q…tjau
_________________________

GM!

GM nostr! Today we'll release multi device feature, and it ...

2026-07-16T08:36:32Z

GM nostr! Today we'll release multi device feature, and it will be smooth af, automatic sync between devices, 0 babysiting. Stay tuned 🚀

GM!

2026-07-15T11:03:25Z

In reply to nevent1q…wzrx
_________________________

GM!

Nostr event nevent1qqsx2sr0gf87mm68v3qfhyh3u2rtrdlv9facp9zfm3gt675l6a6zzkszyqrqursntk7h265qhxrf9jgzfzmgd4j4tpkrrzw2us6sk2xj0m5tuz84dat

2026-07-14T08:30:47Z

Quietly working on the next big leap for Cordn. Stay tuned, lads.

I type a lot already hahaha

2026-07-08T18:02:17Z

In reply to nevent1q…a4k4
_________________________

I type a lot already hahaha

You can just create a new issue and paste the copy there so we ...

2026-07-08T16:31:52Z

In reply to nevent1q…jvn9
_________________________

You can just create a new issue and paste the copy there so we can work over there. Is that or anyother way we can share the copy in text. Much easier for me to integrate it in the website than from an image

New cordn coordinator 0.4.0 is here! This release completes the ...

2026-07-08T14:51:50Z

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!

It will come. One think at time, we are a veeery small team ...

2026-07-07T21:48:15Z

In reply to nevent1q…y8jr
_________________________

It will come. One think at time, we are a veeery small team pushing as hard as we can. A native app is around the cordner ;)

Just send me a msg ...

2026-07-07T21:47:01Z

In reply to nevent1q…7u9q
_________________________

Just send me a msg https://cordn.net/p/npub1qc8quy6ah46k4q9es6fvjqjgk6rdv42cdsccnjhyx59j35n7azlq7ntwss

Yes, cordn is very signer friendly indeed.

2026-07-07T21:46:22Z

In reply to nevent1q…m3hk
_________________________

Yes, cordn is very signer friendly indeed.

What do you think? Already live! ...

2026-07-07T17:33:49Z

In reply to nevent1q…0s7c
_________________________

What do you think? Already live!

Man that would be amazing! 💛

2026-07-07T17:13:20Z

In reply to nevent1q…ykyv
_________________________

Man that would be amazing! 💛

Oh, thank you so much! I like it. I’ll definitely update the ...

2026-07-07T08:40:47Z

In reply to nevent1q…ua3j
_________________________

Oh, thank you so much! I like it. I’ll definitely update the landing page. Please keep the feedback coming! :)

I think you are clearing all or using multiple devices. Currently ...

2026-07-06T18:17:45Z

In reply to nevent1q…4fsz
_________________________

I think you are clearing all or using multiple devices. Currently if you clear everything you start over. And multi device support is coming

No error, nothing? I've messaged you there 👌

2026-07-06T08:02:21Z

In reply to nevent1q…h6pn
_________________________

No error, nothing? I've messaged you there 👌

Multi-device support is coming along nicely. We already have it ...

2026-07-04T16:41:40Z

Multi-device support is coming along nicely. We already have it working in our dev branch, and feels like magic ✨ We're still polishing it, but we're confident we'll have it ready by next week!

quoting
nevent1q…k3d5
These devs are SHIPPING

https://github.com/Cordn-msg/cordn/blob/feat/multi-device/spec/applications/multi-device.md
nevent1q…awpx

Oh yes, indeed! This is built on top of MLS (an emerging internet ...

2026-07-04T09:21:53Z

In reply to nevent1q…7w03
_________________________

Oh yes, indeed! This is built on top of MLS (an emerging internet standard) and presents some UI/UX challenges. I’d love for you to try cordn.net and share your thoughts. We’ve done our best to create a good and consistent UI/UX, though it’s not currently super focused on being user-friendly. For now, we’re prioritizing power users due to these challenges, so it have more fidelity and transparency. Please take a look, and it would be amazing if you’d like to contribute!
If you like please join us: https://cordn.net/chat/dfa7475d-c9ef-46df-bf85-1f481fdcf2c4?m=eyJuYW1lIjoiQ29yZG4gRGV2IiwiaWNvbiI6IvCfqqIifQ

Yes! up to the devs! The spec is open. Probably we will release ...

2026-07-03T20:21:08Z

In reply to nevent1q…69c5
_________________________

Yes! up to the devs! The spec is open. Probably we will release an sdk eventually. But with the spec and the references should be good already

We’ve started working on the multi-device spec! I already have ...

2026-07-03T14:23:31Z

We’ve started working on the multi-device spec! I already have a solid draft for it, along with test cases. If you’d like to review it, please take a look
https://github.com/Cordn-msg/cordn/blob/feat/multi-device/spec/applications/multi-device.md

Nostr event nevent1qqs858pr6pafdpn40c4zgpyyaethsg6wjf4lmeptt8qt97dkcwwd93czyqrqursntk7h265qhxrf9jgzfzmgd4j4tpkrrzw2us6sk2xj0m5tu29kx3u

2026-07-03T06:47:00Z

GM GM!

Thanks! Appreciate the mirroring :) I'm curious to know what ...

2026-07-03T06:43:37Z

In reply to nevent1q…eel8
_________________________

Thanks! Appreciate the mirroring :)
I'm curious to know what are your thoughts on cordn. Do you like it?

🫶

2026-07-03T06:42:40Z

In reply to nevent1q…eel8
_________________________

🫶

🫶

2026-07-03T06:42:28Z

In reply to nevent1q…z40x
_________________________

🫶

hahaha it was lying somewhere in my fs. Pure gold!

2026-07-02T19:14:44Z

In reply to nevent1q…n43j
_________________________

hahaha it was lying somewhere in my fs. Pure gold!

Hahaha, grassroots ftw! The npub will come, in the meantime, feel ...

2026-07-02T19:13:12Z

In reply to nevent1q…wvr4
_________________________

Hahaha, grassroots ftw! The npub will come, in the meantime, feel free to tag me anytime

Oh you’re going to make me sweat through my eyes 🥲💛 ...

2026-07-02T19:12:03Z

In reply to nevent1q…sgnk
_________________________

Oh you’re going to make me sweat through my eyes 🥲💛 thanks for your words

Encrpyted media spec: ...

2026-07-02T14:36:40Z

In reply to nevent1q…74ke
_________________________

Encrpyted media spec: https://github.com/Cordn-msg/cordn/blob/master/spec/applications/encrypted-media.md

🔥 Exciting news 🔥 Encrypted media and pinned ...

2026-07-02T14:35:26Z

🔥 Exciting news 🔥 Encrypted media and pinned messages🖼🔐📌

Now you can share files and media in Cordn, and it is end-to-end encrypted. Also messages can now be pinned to the top of the chat. ✨

We added a new application spec to Cordn that defines how to encrypt and decrypt media for the chat. A photo or document is sealed on your device before it ever leaves, with a key derived from the group's own shared session, and only members can derive the same key to unlock it. The coordinator and the storage layer only ever see opaque bytes. They can store and relay the file, but they can't read it.

For storage, the default is Blossom, though the spec doesn't mandate it. That keeps Cordn aligned with the Nostr ecosystem's media layer while leaving room for other backends. The practical size limit for a file comes from whatever server you choose.

In the web app you can now upload and share files and media straight into your groups. You can configure which servers Cordn uses for uploads, and we ship a curated list of Blossom servers that are friendly to opaque encrypted bytes.

Any media link you paste into a message also renders inline now, so an image or video URL shows up as a preview instead of a bare link. And under Config → Media you can choose whether images and avatars load automatically, useful on a metered connection.

The second feature is pinned messages for groups. Anyone in a group can pin a message, and pinned ones gather in a carousel at the top of the chat. Jump straight to any of them, or open the full list to see them all and unpin. Each pin shows who pinned it.

A lot of media polish landed alongside:

• Tap any image to open it full-screen: zoom in or out (even past 100%), drag to pan, double-tap to fit, and save a copy.
• Download any shared file or image straight from its message menu.
• Media you've opened stays loaded when you scroll away and come back.
• Links, mentions, and previews now render in the message info panel too, not just in the chat.
• Avatars and banners respect your "load avatars" choice everywhere: chat bubbles, profile cards, and the group and direct-message list.

The complete list is available at https://cordn.net/chat/news

Aren't you using Cordn yet? Just start chatting at https://cordn.net/

If you like the project and want to see it grow, please consider contributing in any way you can. Every bit counts, report a bug, contribute with your expertise, send some sats. We are building this together in the open 💛

Nostr event nevent1qqsx3actqsgc6va82j23w82kvf4a85hj2eny76w4xgzvfptwf45c7rszyqrqursntk7h265qhxrf9jgzfzmgd4j4tpkrrzw2us6sk2xj0m5tu3lc6kp

2026-07-01T17:02:49Z

Buckle up! Great new features are on the way 🚀

Indeed, that’s one of the reasons we’re building Cordn the ...

2026-07-01T16:57:34Z

In reply to nevent1q…n32c
_________________________

Indeed, that’s one of the reasons we’re building Cordn the way we are, where nothing resides on relays, which are used merely as dumb pipes/ephemeral message buses. The actual storage happens where you can have control: the coordinator.

I like how Gzuuus (npub1gzu…a5ds) framed it in their article:

> Selection among uncontrolled infrastructures is not sovereignty over them.

Nostr for identity and CVM for interaction already gets you close to what you’re describing, without heavy dependencies like DHTs or blockchains.

Any message in a Cordn conversation now opens into a full info ...

2026-06-30T17:34:10Z

Any message in a Cordn conversation now opens into a full info panel, the thread around it, who reacted and with what, and its delivery status, all in one place. ✨

Until now, message info lived behind a button buried in the overflow menu, and it only showed the raw event envelope. If you wanted to understand a message in context, what it was replying to, who had reacted, whether it had been edited, you had to piece it together yourself. The new panel brings all of that into a single view, with the full reply chain laid out as a proper thread.

While we were in there, we rethought how you interact with a message:

• The Info button now sits next to Reply and React on every message, so it is one tap away instead of hidden in a menu.
• From the panel you can jump straight back to any message in the chat, the one you're viewing or any other in the thread. On desktop the panel stays open beside the conversation; on mobile it closes so you land right where you need to be.
• The thread view indents replies by depth (and keeps deep conversations readable), so a long back-and-forth no longer collapses into a flat list.

Also in this release:

🐛 When a message you had replied to got deleted or edited, its reply preview kept showing the original text. It now reflects the current state, "This message was deleted" or the edited content, so the conversation reads honestly.

The complete list is available at https://cordn.net/chat/news

Aren't you using Cordn yet? Just start chatting at https://cordn.net/

If you like the project and want to see it grow, please consider contributing in any way you can. Every bit counts, report a bug, contribute with your expertise, send some sats. We are building this together in the open 💛

Okay, the latest updates to the Cordn coordinator and web app ...

2026-06-30T08:55:12Z

Okay, the latest updates to the Cordn coordinator and web app have been a bit boring. We’ve been focusing on bug fixing and reliability. Now it’s time to get back to the fun stuff ahead! :)
Buckle up!

Joining a group in Cordn is now as reliable as it should have ...

2026-06-29T19:18:39Z

Joining a group in Cordn is now as reliable as it should have always been. 🛠

If you ever left a group and asked to rejoin, you may have hit an annoying glitch: your join request wouldn't reach the admins until you sent it a second time (or hit "reset request state"). It was subtle, persistent, and it took us a proper bug hunt to pin down.

While we were in there, we cleaned up the rest of the join-request flow:

• You no longer see your own join request in your notifications after being re-added to a group where every member is an admin.
• Stale join-request notifications for groups you no longer administer are cleaned up automatically.
• An admin can now accept a join request from someone who is still technically in the group — they are cleanly removed and re-added instead of the accept silently failing.

Also in this release:

✨ Coordinators now display the name their server advertises when available, with your custom label still taking priority. A coordinator's page also shows its about text, website, and picture.
🔄 Sending a message no longer waits on an unrelated coordinator that is having trouble — only the group you are messaging waits for its own coordinator, so healthy groups stay snappy when another one is slow to reconnect.
🔄 The sidebar finishes loading sooner after sign-in: join requests and key packages no longer wait for every group subscription to finish opening.
🐛 The New conversation dialog and chat home now show exactly the same key-package list, so the two can no longer drift apart after a refresh.
🐛 The key packages settings page now stays in sync with the rest of the app — creating or removing a key package updates every list immediately.

The complete list is available at https://cordn.net/chat/news

Aren't you using Cordn yet? Just start chatting at https://cordn.net/

If you like the project and want to see it grow, please consider contributing in any way you can. Every bit counts, report a bug, contribute with your expertise, send some sats. We are building this together in the open 💛

gm semi!

2026-06-29T11:55:14Z

In reply to nevent1q…pwqe
_________________________

gm semi!

Announcing a new specification for Cordn: sealed group payloads. ...

2026-06-29T08:17:18Z

Announcing a new specification for Cordn: sealed group payloads. 🔒

Are messages decryptable by the coordinator? No, they never were. MLS already encrypts your message with very fancy crypto. This new specification doesn't change that; it only reduces interpretability to the maximum.

Previously, the MLS wire framing still leaked the epoch number (a curious coordinator could watch epochs tick over). Spec/03 seals each payload under a key derived from your group's current MLS epoch secret, so the coordinator now just stores gibberish. It learns nothing. Not the content, not the epoch, not even the framing that says "this is MLS." Read the spec: https://github.com/Cordn-msg/cordn/blob/master/spec/03.md

A bonus consequence: since the routing group ID is now something the client supplies, groups could rotate their group ID from the coordinator's perspective, which also enhances privacy and reduces interpretability from the coordinator's point of view.

We upgraded the Cordn coordinator to version 0.3.x to implement this cleanly. We are rolling it out progressively in our web client, and it is opt-in for now:

• Old and new clients coexist transparently in the same group; sealed and plaintext messages mix seamlessly.
• You can enable it from any group's info page, under the 'advanced' dropdown.
• Once we are confident, sealed payloads will become the default.

We are testing this in the open, so feel free to enable it and break things. Found a bug? Let us know. 🐛

Also in this release, we have made some app improvements:

✨ Backup & recovery: export keys, group secrets, and coordinators; restore on a fresh device.
🐛 Some minor bug fixes.
🔄 Some minor changes.

The complete list is available at https://cordn.net/chat/news

Aren't you using Cordn yet? Just start chatting at https://cordn.net/

If you like the project and want to see it grow, please consider contributing in any way you can. Every bit counts, report a bug, contribute with your expertise, send some sats. We are building this together in the open 💛

Yes, that’s true. I forgot that users don’t want to be free. ...

2026-06-28T20:24:05Z

In reply to nevent1q…5leq
_________________________

Yes, that’s true. I forgot that users don’t want to be free. Nostr relays also sound like a feature for power users to me, and it’s the same issue here. How do users choose their relays? How do they choose their coordinators?

We’re running our own for the community as the default in the app. But ideally, users who want true freedom and sovereignty should run their own to avoid depending on a third party.

Maybe we should add the default coordinator when users log in and just prompt them to get started. However, since the app is still being developed, we thought it best to focus first on power users.

The thing is that users need a coordinator set up in order to ...

2026-06-27T15:48:52Z

In reply to nevent1q…wvrc
_________________________

The thing is that users need a coordinator set up in order to start chatting. If we remove step 2, I feel users would be more confused since only power users would configure their own coordinators for now, and I don't feel comfortable setting up configurations for them. Well, we could indeed set the coordinator by default, but not publish a key package since that feels more intrusive, current step 2 does these two things. Configuring the default coordinator doesn't have any implications for the user. Then step 2 could simply be "let people find you," which could publish a key package. And step 3, "start chatting," would mean creating a group or starting a chat with already available people. What do you think?

Step 2 is to set up the default coordinator and publish a key ...

2026-06-27T15:10:42Z

In reply to nevent1q…h4sk
_________________________

Step 2 is to set up the default coordinator and publish a key package (which allows others to chat with you) in it. This is done this way because users don’t need to use the default coordinator if they’re running their own for example. How would you abstract this away? I’d love to hear your design recommendations :)

I don’t make the rules… At most, two or three people work on ...

2026-06-27T11:14:11Z

I don’t make the rules… At most, two or three people work on this in their spare time, with only one of them putting in a bit more effort. There’s no funding so far aside from community contributions. Driven by the vision of empowering people to have alternative, private, and sovereign communications, and, of course, love 💛

quoting
nevent1q…gt7n
This actually works, white noise does not. Proof that high budget does not yield high results.

Gzuuus (npub1gzu…a5ds)
nevent1q…892e

🚀 New Cordn Web update live. We smoothed out the coordinator ...

2026-06-26T16:12:43Z

🚀 New Cordn Web update live.

We smoothed out the coordinator and group-joining experience:

🔹 Coordinators are now saved automatically when you join a group or publish a key package — the separate "Save locally" step is gone, and joining a group can no longer silently change your default coordinator.

🔹 The New conversation dialog and the key-package directory now reflect coordinators you've joined the moment you join them — no manual save, no page refresh.

🔹 Stuck waiting on a join request? You can now hit "Request again" from the group page. Sent requests clear automatically once you're actually added.

🔹 Fixed: coordinators you just joined sometimes connected through the wrong relays.

The complete list of news at https://cordn.net/chat/news

Free and open source, as always 🫶

#nostr #cordn #opensource

Great post :D https://stacker.news/items/1513682

2026-06-26T10:20:07Z

Great post :D
https://stacker.news/items/1513682

Chinese elites too?

2026-06-26T09:56:21Z

In reply to nevent1q…fak9
_________________________

Chinese elites too?

GM!

2026-06-26T09:55:43Z

In reply to nevent1q…f3df
_________________________

GM!

Great session today! Bug fixes and new features. Please check the ...

2026-06-25T17:42:57Z

Great session today! Bug fixes and new features. Please check the https://cordn.net/chat/news for the full list of changes

Yes, man! Great analysis 🤘 > Remember that the relay ...

2026-06-25T17:07:52Z

Yes, man! Great analysis 🤘
> Remember that the relay operator was defined as the scary vantage point because it sees the protocol-level events and the network layer in the same hands: what you do and where you are, at once. Cordn severs that convergence. [...] The party that can interpret the traffic cannot locate you, and the party that can locate you cannot interpret the traffic.

quoting
naddr1qv…934r

Private communications over public infrastructure

Rev.1

Today I want to write down some thoughts on what it really means to have private communications over public infrastructure, and whether such a thing is even possible at all.

This article was motivated (or should I say triggered?) by several things. Part of it comes from the current state of DMs in Nostr. Part of it comes from the privacy claims different projects make. And part of it comes from recent conversations I have had, also because I care about privacy. Privacy is crucial. We need to fight for it, and if we get it wrong and just assume things are private when they are not, things are going to get very scary.

I want to set the ground first, then look at the privacy model and tradeoffs of the main private-communication approaches built on or around Nostr: NIP-04, NIP-17, Marmot, Nostr Double Ratchet, Concord, Nymchat, NIP-4e, and Cordn.

First things first: private communications and encrypted communications are not the same thing.

Private communications usually depend on encryption to protect message content. But encryption alone is not enough to make a communication system private. You may encrypt what you say, yet still expose who you are talking to, when you are talking, how often you are talking, where you are connecting from, and how large your messages are. A third party can still learn a lot. This is metadata leakage, and in many cases, it is enough to build a revealing picture of relationships and behavior between different parties without reading a single message. Metadata is not "just data." It is actionable intelligence.

In other words: Encryption protects what you say; privacy protects that you said it at all.

That distinction matters a lot in Nostr because Nostr was never designed as a private messaging network. It was designed to be an open network built around relays. Those relays are meant to be queryable, subscribable, "dumb", and easy to use as public dissemination infrastructure. That design is powerful for openness and censorship-resistance, but it is hostile to strong privacy by default.

The next thing I want to clarify is the concept of public infrastructure. From the perspective of this article, it refers to shared, openly accessible systems or mediums, sometimes controlled by a third party, that anyone can use but that lack inherent controls to prevent interception, inspection, or eavesdropping by unauthorized parties. In this context, that includes networks, protocols, and services like relays.

Public infrastructure fights privacy at every layer, which is exactly why the distinction between encryption and privacy matters so much here.

One historic precedent makes this easier to understand. During World War II, encrypted radio traffic itself was not always immediately decryptable, but the metadata around that traffic was already useful. Timing, frequency, origin, volume, and communication patterns helped infer enemy movements, unit locations, and operational behavior. In other words, not being able to read the message did not mean the communication was private. The metadata still spoke loudly, and that lesson maps uncomfortably well to modern digital systems.

"We kill people based on metadata," stated by Michael Hayden, former director of the NSA and CIA, during a 2014 debate at Johns Hopkins University.

"Metadata absolutely tells you everything about somebody’s life. If you have enough metadata, you don’t really need content." Stewart Baker, former NSA General Counsel

That is also why I am skeptical every time I hear privacy claims built on top of public, observable infrastructure. If the substrate is public, queryable, persistently collectable, and operated by third parties, then metadata becomes part of the threat model whether we like it or not.

In Nostr, this problem becomes very concrete.

Even if a DM standard encrypts the content, an observer can still learn a lot. If the observer is a relay operator, it can see when a client connects. It can see the IP unless the user adds another protection layer such as Tor or a VPN. It can see when an event arrives. It can store traffic over time and build heuristics. An external observer with access to the relay stream may also infer a lot, depending on how much metadata the event exposes publicly.

I also think it is useful to distinguish two different kinds of observers throughout this article.

The first is an external observer. This is someone who can collect publicly visible events from relays, subscribe to public streams, and analyze what is exposed in the events themselves. An active observer could also infer the arrival time of an event even if its timestamp is randomized. This observer does not necessarily run the relay.

The second is a relay operator observer. This observer has a much stronger vantage point. They can see connection timing, source IPs unless users hide them, exact arrival timing, authentication attempts, and all the relay-local heuristics that never appear in the event itself.

That distinction matters because some protocols hide more from the external observer than from the relay operator. A scheme can look much better at the public event layer while still leaking a lot to the operator actually serving the traffic.

There is one more thing the relay operator can see that I want to name explicitly, because every protocol in this article is affected by it and we will come back to it. When a client fetches from a relay, it does not just receive events. It also publishes a subscription filter describing what it wants. That filter is metadata too, and it is almost never obfuscated. So even protocols that hide content, and that partially hide the author inside the event, still broadcast their routing interest at subscription time. I will call this filter observability, and it belongs specifically to the relay operator vantage point, since the external observer sees only published events and not your subscriptions.

I also want to push the relay operator model one step further, because it is easy to think of relays as passive storage with a few policies attached. They are not. They are active participants. A relay can delay, drop, or reorder a specific user's events. It can selectively serve stale or incomplete state. It can fingerprint a user through its filters and act on what it learns. It can refuse service entirely. Redundancy across many relays lowers the chance that any single relay harms you, but it does not remove the class of risk, because you still do not control the substrate you depend on. That will matter later when we talk about sovereignty, because the word is doing more work than it should.

There is an attempt to mitigate part of this for external observers with relay auth, aka NIP-42, which allows clients to authenticate to relays. That can help a relay restrict access to sensitive events. But NIP-42 is not a privacy cure. It is a gatekeeping mechanism. In practice, it requires the client to reveal its identity to the relay in order to gain access. And for a relay to know which private events a user is allowed to fetch, those events usually need enough routing information to tie them to the relevant participants. That is useful operationally, but it comes with a clear tradeoff: access control becomes entangled with metadata exposure.

So the question I want to explore in this article is not whether Nostr can carry encrypted messages. It clearly can. The real question is whether it can support private communications over public infrastructure in a strong sense, or whether what we really get are different degrees of content secrecy with different amounts of metadata leakage.

That is the lens I want to use for the rest of this article.

NIP-04

NIP-04 was the first DM standard Nostr had. Today it is deprecated and explicitly marked as not recommended in favor of NIP-17, but it remains the cleanest example of the distinction I am trying to make.

In NIP-04, the message content is encrypted, but the event metadata is highly revealing. The event is authored by the sender’s real pubkey, although anyone could use an ephemeral pubkey. The receiver is identified in a p tag. The timestamp is visible. The event kind is visible. And the ciphertext size is visible as well.

That means the content may be hidden, but the communication pattern is not.

If you are an external observer collecting these events, you can map who is talking to whom and when. If you are a relay operator, you can usually do even better because you also see connection-level information and exact receipt timing. Even if a client tries to blur some timing details, the relay still sees when the event actually arrived.

So what does NIP-04 really give us? It gives us encrypted content, but it leaks social graph information, timing, sender identity, receiver identity, and payload size. That is already enough for strong traffic analysis. You do not need to decrypt anything to extract valuable intelligence from it.

This is not even a controversial interpretation. The specification itself warns that it leaks metadata and says it should not be used for anything that really needs to be kept secret, except perhaps in combination with authenticated relay restrictions from NIP-42.

That said, there is one thing NIP-04 does have going for it. Since sender and receiver are explicit, it works relatively naturally with relay authorization models. A relay can restrict access to the parties involved because the parties are visible in the event. But that convenience is also part of the privacy failure. The same metadata that helps a relay gate access also helps an observer understand the communication graph.

So NIP-04 is simply encrypted communication, but not private communication in any strong sense. It is the perfect example of why those two ideas must not be conflated.

NIP-17

After NIP-04, Nostr moved toward NIP-17, which uses NIP-44 encryption together with gift wraps. This was a real step forward.

The biggest improvement is that NIP-17 does a better job hiding the sender from the public outer event. The gift wrap is authored by an ephemeral key, and the actual message with the real sender is carried inside nested encrypted layers. On top of that, clients are encouraged to randomize timestamps to make simple timing correlation harder.

All of that is meaningful. I do not want to undersell it.

But I also do not want to pretend it solves the problem.

The receiver still needs a way to receive messages. In practice, that means the outer event still carries routing information for the receiver. An active observer can see that gift wraps are being delivered to some receiver-facing key. It can observe timing, volume, relay overlap, and ciphertext size. If the observer is a relay operator, it can also observe connection behavior. An external observer may not get the full picture that NIP-04 leaks publicly, and that is an important improvement, but important metadata is still available.

There is also another tradeoff that matters for the broader story. Gift wraps help obscure purpose because the same mechanism can be used for more than just DMs in Nostr. More specifically, the kind gift wraps use, 1059, is not exclusive to private chats. That is genuinely good for privacy, since not every gift wrap is obviously a chat message. An external observer seeing a kind 1059 event cannot automatically conclude that it is DM traffic. But the same design also creates a broad spam surface. An attacker can cheaply create many gift-wrap-looking events for a target receiver and force the receiver to spend resources figuring out which ones are real, or bury them under a pile of fake gift wraps. This spammy nature is also why some relays do not accept them.

I do not want to focus too much on UX in this article, but this is one of those places where privacy and usability pull in different directions. NIP-17 also gets awkward with relay authentication because the sender uses an ephemeral key, so it does not have a clean way to prove it should be allowed to fetch these events.

So I would describe NIP-17 as a meaningful improvement over NIP-04, especially in sender concealment, deniability, and reduced public visibility. But I still would not call it fully private communication. It is better encrypted communication with a more cautious metadata posture, but not a complete escape from metadata leakage.

Beyond The NIPs Umbrella

The Nostr repository itself mainly gives us NIP-04 and NIP-17, plus the new NIP-4e, which is still a PR. But there are other serious attempts to push the privacy and security model further, and they do not all push in the same direction.

The first two I want to look at, Marmot and Nostr Double Ratchet, bring in much stronger messaging primitives. Marmot brings MLS. Double Ratchet brings the family of ideas popularized by Signal. In both cases, the cryptography becomes substantially more ambitious, giving us things like forward secrecy and post-compromise recovery, which neither NIP-04 nor NIP-17 gives us.

These terms, forward secrecy and post-compromise recovery, basically mean that if a private key is compromised, an attacker should not automatically be able to read historic messages or future messages.

That matters, but it still does not let us skip the transport question. And it is worth saying early that these two are not the whole story. Reading the field as a steady climb, where each new protocol is simply more cryptographic than the last, is tempting but wrong. Later I will look at Nymchat, which takes nearly the opposite route and hardens NIP-17's metadata surface from the client side rather than strengthening the cryptography; Concord, which deliberately gives up some of that cryptographic strength to buy scalable community chat; and Cordn, which questions a premise all of these schemes share, namely that messaging artifacts must be published to public relays at all. The tradeoff space has more than one dimension, and naming that is part of being honest about what each design actually gives you.

Marmot

Marmot combines MLS with Nostr. MLS, short for Message Layer Security, is a serious group messaging protocol designed to provide strong content confidentiality, authentication, forward secrecy, and post-compromise recovery for groups. It also scales much better for larger groups than Double Ratchet. Those are not small properties. They are major upgrades compared with the simpler encrypted-message schemes we find in NIP-04 or NIP-17.

This is something that should be said clearly: MLS gives Marmot genuinely strong secrecy properties at the message layer.

But the problem I am exploring here is not just message secrecy. It is private communications over public infrastructure. That is where the picture becomes more complicated.

Marmot maps MLS artifacts onto Nostr events and uses relays as a dissemination layer. That means things like key packages, welcome flows, group events, and group routing all have to live within a public relay environment. The protocol tries to preserve privacy through encrypted payloads, private MLS group IDs, ephemeral outer pubkeys for group events, and other techniques. Those are meaningful design choices, and they do improve the situation.

But there is an important nuance here. The private MLS group ID and the relay-facing nostr_group_id are not the same thing. In theory that is good because the real internal MLS group identifier stays private. In practice, though, the relay-facing nostr_group_id still behaves like a stable public routing identifier. That means it is observable, it is collectable, and it is spammable in the same way gift wraps are. So even if it is not the real MLS group ID, it still creates a public handle that observers and attackers can use.

This matters even more because Marmot traffic is not especially hard to identify from the outside. If a user publishes key package events on kind 443, or on kind 30443 in the newer transition, that already signals that the user might be using Marmot. And if an observer subscribes to group messages which are kind 445 events, they can infer Marmot group traffic directly. Those event kinds are not generic cover traffic. They are much more revealing than NIP-17 gift wraps, whose kind 1059 can be used for several different purposes in Nostr.

From my perspective, I do not think its current design gets Marmot to strong privacy in the way some descriptions suggest.

The reason is simple. Marmot still operates over public relays. Even if the content is well protected, relays and active collectors can still observe that Marmot is being used. They can see when certain group identifiers become active, when bursts of traffic happen, how much data is flowing, how large the messages are, and which relays appear to be involved. An external observer can infer protocol usage from the specific Marmot kinds used and from the stable routing surface. A relay operator gets all of that plus the usual network-level vantage point, exact arrival times, and IP-level heuristics.

There is another issue: MLS is not just cryptography. It is also coordination. That burden becomes harder in Nostr because relays are a dissemination substrate, not an ordering oracle. Multiple admins can race. Offline members can come back with stale state. Welcome flows and commits need careful discipline to avoid drift.

This is not mainly a privacy problem, but it matters because every time a protocol needs more coordination over weakly ordered public infrastructure, the system inherits more complexity, more observable recovery patterns, and more room for operational fragility. As I already said, I do not want to turn this article into a UX piece. But this is exactly one of those places where the search for stronger privacy and stronger secrecy can make the total system harder to operate.

So my conclusion on Marmot is nuanced.

I think Marmot substantially improves content security and secrecy compared with simpler DM schemes. Thanks to MLS, it brings real forward secrecy and post-compromise recovery, and that is a serious advancement. But I do not think public Nostr relays let Marmot honestly claim strong private communications in the broader sense. Metadata observability and public collection remain very real constraints.

There is an in-progress Marmot v2 draft worth noting because it touches the routing critique directly. v2 formalizes nostr_group_id as admin-gated, rotatable group state, and pins that the value must be cryptographically random and never derived from any member key, which closes one specific cross-group linkage path. But rotation is opt-in rather than scheduled, the rotation commit is published at the old address so the handoff itself is observable and links old to new, and historical traffic stays clustered under the old identifier forever, so v2 softens the stable-routing-ID problem without removing it. The rest of v2, a convergence engine with formal proofs, is correctness and interop work rather than a privacy advance.

Nostr Double Ratchet

Nostr Double Ratchet is the closest thing in this space to bringing a Signal-like messaging primitive into Nostr instead of relying on simpler static encryption flows.

Double Ratchet gives us stronger secrecy properties thanks to forward secrecy and post-compromise recovery. Instead of deriving a static conversation secret and reusing that basic relationship forever, the ratchet evolves keys as messages are exchanged. In practical terms, that means a compromise now should not automatically reveal all past messages, and if the compromise ends, future secrecy can recover after fresh ratchet steps.

That is real progress. Just like with MLS, I think this should be acknowledged clearly rather than buried under transport criticism. If the question is message secrecy, Double Ratchet is much closer to the state of the art than NIP-04, and in an important sense it also improves on the baseline security model around ordinary NIP-17-style direct messaging.

At the same time, Nostr Double Ratchet does not get to cheat physics.

The messages still move through Nostr events and relays. And here the event kinds matter more than they may seem at first glance. In this design, the encrypted outer transport for ordinary ratcheted messages uses kind 1060. That is important because kind 1060 is not generic cover traffic. If an external observer sees repeated kind 1060 events, they can reasonably infer that this specific messaging system is in use, just like in the case of Marmot.

Not every part of the protocol is equally revealing. Invite and AppKeys records use kind 30078, which is a general application-data kind in Nostr and does not by itself prove that Double Ratchet is being used. Encrypted invite responses use kind 1059, which blends into the broader gift wrap universe. Shared-channel bootstrap also leans on kind 4. So there is some reuse of more generic Nostr surfaces. But the core ratcheted message transport still stands out.

That means the outer layer is still informative. An external observer can learn that kind 1060 traffic is happening, see the outer event pubkeys, timestamps, traffic bursts, approximate message sizes, and repeated communication rhythms. Even if they cannot read the content, they can still cluster activity, try to infer which identities or devices are active, and distinguish steady chat traffic from bootstrap traffic such as invites or device-management updates. Those flows also use protocol-specific kinds that do not blend into the general Nostr event stream.

The relay operator learns even more. It sees exact arrival times, subscription behavior, source IPs unless users hide them, and the full local timing picture that never appears in the event itself. At the same time, Double Ratchet does seem to avoid one of the more obvious metadata problems we saw in Marmot: ordinary traffic does not depend on a stable public routing identifier in the event itself.

There is also a tradeoff here around scale. Double Ratchet is naturally attractive for 1:1 communication because it gives strong secrecy with relatively clear security intuition. But it is not the most natural fit for large fanout by itself. The moment it tries to scale those guarantees into more complex group and multidevice environments, the protocol surface and complexity grows quickly. The Nostr Double Ratchet project itself includes multidevice identity mapping, session management, and sender-key-style group messaging, and that is powerful, but it also shows the cost of pushing stronger security models over a public relay substrate. The event kinds used reflect that expansion. Once a system needs separate kinds for encrypted transport, invites, device authorization records, shared-channel bootstrap, and group sender-key flows, an observer gets more protocol fingerprints to work with even if the message bodies remain sealed.

So my take is that Double Ratchet is a major upgrade in secure messaging properties, and it may improve privacy in a limited sense by making traffic less trivially interpretable. If I have to choose a protocol for 1:1 communication over Nostr relays, it would be this one. But it still does not solve the central problem of public infrastructure. The relays still know that communication happened. They still see timing. They still see patterns. And if the infrastructure remains public and observable, those patterns remain part of the attack surface.

Just a side note to finish this. Neither Marmot nor Nostr Double Ratchet play well with relay auth, NIP-42.

Concord

Concord is the protocol behind Vector's Communities, and it is worth looking at because it makes a tradeoff none of the others in this article make, and because it forces us to stop reading the field as a single ladder.

So far the story has looked like a steady climb. NIP-04 to NIP-17 to Marmot to Double Ratchet, each step bringing stronger encryption primitives, with Marmot and Double Ratchet reaching for forward secrecy and post-compromise recovery. It is tempting to read that as one axis, where each new protocol is simply more cryptographic than the last. Concord is the proof that the tradeoff space has more than one dimension.

Before I get into the tradeoffs, one honest caveat about how I am analyzing it. Concord does not have a written specification. The Vector README and the "Understanding Concord" guide are well-written prose, but they describe the product more than they define the protocol. The authoritative behavior lives in the Rust crates, and the team itself says the code is the spec, with golden-vector tests serving as cross-implementation reference points. So everything I say here about Concord is inferred from the code, not read from a document. That matters for an article whose whole argument is that honest, auditable language is part of security. A protocol you can only know by compiling it is harder to hold to its own claims, especially at the metadata layer where informal descriptions tend to be optimistic.

With that said, Concord is built for Discord-style communities: many channels inside a community, roles, admins, bans, the things people actually expect from a group platform. To get there it makes a set of choices that are genuinely well-considered. It uses a shared symmetric channel key per channel and per epoch, so a message is sealed once and every member decrypts the same blob. That is O(1) broadcast, and it is a real property none of the gift-wrap-style schemes have. A room of hundreds of people does not mean hundreds of sealed copies of every message. Authority is handled elegantly too: roles, grants, and bans are real-npub-signed, version-chained records that every member re-derives independently. There is no shared admin key to leak or rotate; authority is a provable place in a signed list, not a secret. And every message carries a real-npub signature inside the encryption, bound to its exact channel and epoch, so forged messages and cross-room splices are detectable even when they come from a key-holding member.

But here is where it matters for this discussion, and I want to be direct. Concord deliberately gives up the two properties Marmot and Double Ratchet worked hardest to provide. It has no forward secrecy and no post-compromise recovery, and that is not an oversight. It is the cost of the random-access epoch model that lets members skip epochs and still catch up. Rekeys use static ECDH between long-term identity keys. The consequence is severe and I want to state it cleanly: if your identity key is ever compromised, an attacker can recover every message you ever had access to, across all of your communities, all channels, all time. There is no cryptographic healing. The only remedy is an admin banning that identity from each community individually.

The shared-key design also widens the blast radius. Because the channel key is symmetric and held by every member, one compromised device exposes the entire channel for that epoch, not just that member's messages. The server root key is broader still. That is the tax on O(1) broadcast: you trade per-member isolation for scale.

And on the question this article keeps coming back to, namely metadata, Concord does not improve on the relay-based schemes. Let me separate the two observers the way I did for the other protocols.

For an external observer just collecting events, Concord is actually one of the most legible designs in this article. Its event kinds, in the 3300 range, are Concord-specific and immediately fingerprintable, and unlike NIP-17's generic kind 1059 they reveal the operation type. An observer can tell message traffic from reactions, edits, rekeys, kicks, and typing indicators. The relay-facing pseudonym, the z tag, lets an outsider group all the traffic for one channel together. Outer events carry real timestamps to the second, not randomized ones, which makes timing correlation easy. So even without running a relay, a collector can confirm Concord is in use, distinguish the operation types, cluster channels, and read traffic rhythms.

The relay operator gets all of that and more. It also sees source IPs, connection timing, exact arrival times, and, returning to the filter observability point from earlier, the subscription filters. That last one bites Concord hardest of all the relay-based protocols, because a client subscribing to a channel has to ask for those specific kinds and that specific channel handle. The subscription itself tells the relay that Concord is in use, which channel the user belongs to, and roughly what operation they are waiting on. That is a lot of structure handed to the relay operator for free.

There is one more nuance worth being candid about. That relay-facing pseudonym rarely rotates. A Public community keeps one stable, trivially-clusterable identifier for its entire lifetime; only bans in a Private community trigger a rotation. So this is not a privacy feature that happens on a schedule. It is a recovery event. But Concord is also a young protocol, and this is exactly the kind of thing that could improve. Scheduled or periodic rotation of that routing pseudonym would meaningfully reduce clusterability, and nothing in the architecture prevents it. The critique here is about the design as it stands today, not a verdict on where it could go.

So where does Concord sit? I would describe it as encrypted communication, not private communication, same as the others, but for a different mix of reasons. It is the design to reach for if the threat model is "no company and no central server reads our community's messages, and we want it to scale," and where long-term identity-key compromise is not the primary concern. It is a poor fit if forward secrecy matters, if metadata matters, or if a compromised member should only expose their own messages. Naming that explicitly is the point. The tradeoff space is not a ladder, and calling Concord more or less private than Marmot without specifying the axis is exactly the kind of imprecision this article is arguing against.

Nymchat

Nymchat, or NYM, takes a route none of the other designs in this article take, and it works on the metadata rather than the cryptography.

Every protocol since NIP-17 has treated the cryptography as the central move. Marmot reaches for MLS, Double Ratchet reaches for Signal-style ratchets, and even Concord, which deliberately trades secrecy away, is still making a cryptographic choice. Nymchat refuses to touch the cryptography at all. Its private messages and group chats are plain NIP-17: a kind 14 rumor sealed in kind 13, gift-wrapped as kind 1059, one wrap per member per group message. The cryptography is the same NIP-17 baseline I already covered, weaknesses included, and Nymchat does not strengthen it. Instead it attacks the metadata surface around it from the client side. Nymchat also runs public geohash and named channels on ephemeral kinds, but those are public chat and outside what this article is asking, so I will leave them aside.

The genuinely interesting contribution is the rotating ephemeral recipient key. In vanilla NIP-17 group sends, Alice publishes N gift wraps addressed to the N members' real pubkeys, all at once. A relay sees N kind 1059 events to N recurring real pubkeys and reads off group membership, size, and existence, durably, on every single message. That is the leak that makes NIP-17 groups so legible. Nymchat breaks it by having each member generate a fresh ephemeral keypair whenever they send, advertise the new pubkey inside the encrypted rumor, and thereafter receive at that one-time key instead of the real one. Every gift wrap now goes to a never-before-seen recipient address.

That genuinely defeats two things: the durable group fingerprint via recurring recipient pubkeys, and the link from recipient addresses back to real identities for active members. This is a real win, and it is exactly the receiver-facing key leak I described in the NIP-17 section.

But Nymchat's own README overstates what it stops, with the line that relays "cannot correlate group membership, timing, or real identities," and I want to be precise about what it does not stop. It does not hide group size at send time: a relay still sees a burst of N gift wraps, even if the recipient addresses are now one-time. It does not hide timing from a live relay, only from an after-the-fact archive reader, because a live operator records actual arrival regardless of the randomized created_at. And it degrades for exactly the members who are least active, since a member who has never sent has no advertised ephemeral key and must be addressed at their real pubkey. The protection assumes an active, sending membership.

Nymchat also randomizes the gift-wrap timestamp by up to two hours using a secure RNG. That is a real but blunt defense: it blurs created_at so an archive observer querying stored events later cannot trivially cluster a group send. The cost is fuzzy real-time ordering, and again it does nothing against a live relay that records true arrival time. It is aimed squarely at the persistent-archive threat model, not the live-relay one.

Nymchat's profile on the axes this article cares about is unusual, and it is the inverse of the Marmot and MLS trade. On content secrecy, forward secrecy, and post-compromise recovery, Nymchat sits at the weak end: NIP-17 baseline, no real FS for groups, optional DM-only per-message FS, and a soft group recovery piggybacked on sending rather than the cryptographic healing MLS provides. On relay-visible fingerprint, though, Nymchat is tied with NIP-17 as the best-behaved relay-based scheme in this article. By refusing to invent new event kinds, its private traffic is generic kind 1059, indistinguishable from any other NIP-17 DM traffic on the relay, which is strictly better than Marmot's 445, Double Ratchet's 1060, or Concord's 3300 range. On filter observability it is also minimal, since subscribing to your own inbox is the same generic NIP-17 filter every DM client uses. And it has no stable routing identifier for private chats at all, because the rotating recipient keys are specifically a move away from one.

There is one uncomfortable thing the article's lens forces me to flag. The default Nymchat deployment routes through Cloudflare Pages Functions operated by 21 Million LLC, acting as a proxy for relays and media, generating link previews, and running its bot. So if a user runs the default client, an operator sits in the traffic path and can observe IPs, timing, and relay selection. The reproducible-build verification and the warrant canary are real and laudable mitigations for trust in that deployment, but they do not remove the vantage point. This is the "runs a service" tradeoff, and it is the same question that will come up again with Cordn later in this article, except here the service is a third-party operator the user does not control. Nymchat's protocol-level metadata discipline only delivers its full story when the user pairs its default ephemeral identity with a relay set of their own choosing rather than the hosted proxy.

So Nymchat sits at a clear and honest point. It is weaker cryptography than Marmot, Double Ratchet, or Cordn, but more metadata-aware than any relay-based scheme here, and it gets there not by inventing new crypto but by refusing to add new observable structure on top of NIP-17. It does not escape the relays, it inherits NIP-17's cryptographic limits, and its default deployment reintroduces a piece of the observer vantage it works so hard to remove at the protocol layer. But as proof that you can meaningfully improve privacy over NIP-17 without touching the cryptography, it is the strongest example in this article.

NIP-4e

NIP-4e is a bit different from the other things I have covered so far, because it is not really trying to be a standalone DM protocol. It is better understood as an auxiliary mechanism that can be used together with schemes such as NIP-04 or NIP-17.

Its core idea is to decouple encryption from identity.

That may sound subtle, but it solves a real problem. Many Nostr patterns assume the identity key is also the key used for encryption, including self-encryption flows used for syncing data across devices. That breaks down in setups where the identity key is intentionally not present on the device, like bunkers, threshold signing systems, secure enclaves, or other more sovereign key-management architectures. NIP-4e tries to fix that by letting a user keep a separate encryption key and distribute that capability securely across devices.

From an architectural point of view, I think that is a good idea.

It improves key hygiene. It makes local encryption workflows more practical. It lets someone keep their identity signing setup more isolated while still doing encryption on-device. And it fits better with a world where people want a stronger separation between identity authority and application-level encryption.

But if we bring it back to the main question of this article, the answer stays modest.

NIP-4e does not suddenly make communications private. If you use NIP-4e together with NIP-04, you still inherit the metadata exposure of NIP-04, even if the keys used are not the real keys. If you use it with NIP-17, you inherit the strengths and weaknesses of NIP-17. What changes is not the public nature of the transport, but the keying model.

In fact, the protocol introduces a privacy cost of its own that is worth naming directly. The device key-sharing and key-package artifacts that NIP-4e relies on publish each of a user's devices as a distinct public record. An observer can count those devices, watch them come and go, and correlate per-device activity, which means building a fingerprint of someone's hardware footprint and routine without ever reading a message. That is device enumeration, and it sits on top of whichever transport model you pair NIP-4e with, so it persists whether you combine NIP-4e with NIP-04 or with NIP-17. It does not make NIP-4e bad. It just means it should be evaluated honestly. NIP-4e is useful infrastructure for decoupled encryption and multi-device sovereignty, and it can support other DM standards. But by itself it is not a privacy breakthrough, and the device graph it exposes is a real cost to weigh.

Cordn

Cordn is the design in this article that questions a premise all the others share, and I think it is the most interesting one to end on.

Every messaging protocol I have covered so far, NIP-04, NIP-17, Marmot, Double Ratchet, Concord, Nymchat, keeps its artifacts on public relays. Those events are collectable and queryable, and all but Nymchat, which deliberately blends into generic gift-wrap traffic, are fingerprintable to a protocol-specific kind. That is the problem I keep returning to, and up to this point every design has accepted it as a fact of life and tried only to encrypt the content inside.

Cordn does not accept it. To be clear about how it uses Nostr, because it would be easy to misread this: Cordn still runs over relays. What changes is what lives on them. Cordn is a coordinator-assisted MLS protocol, and none of its messaging artifacts, whether KeyPackages, Welcomes, group messages, or join requests, ever persist as cordn-specific events on a relay. Instead they live on a coordinator service, and that coordinator is reached through ContextVM, a general-purpose protocol for reaching services through relays without direct public exposure. The only thing the relay actually carries is generic, encrypted, ephemeral ContextVM traffic, which blends with every other ContextVM usage and does not name groups, channels, recipients, or message types. So Cordn does use Nostr relays as its transport, but it stores nothing on them, and nothing a relay collects can be tied back to a cordn conversation later.

That single architectural difference changes the metadata picture in a way none of the others manage. There are no cordn event kinds for an external observer to fingerprint, nothing like Marmot's 443 and 445, Double Ratchet's 1060, or Concord's 3300 range. Group identifiers are coordinator-internal, not public network-wide artifacts, which is a direct fix to the stable routing identifier I criticized in Marmot. And cordn traffic blends into all the other ContextVM usage on the relay instead of standing out as a legible protocol stream.

Now the part I care about most, because it answers the strongest observer this article set up at the start. Remember that the relay operator was defined as the scary vantage point because it sees the protocol-level events and the network layer in the same hands: what you do and where you are, at once. Cordn severs that convergence. The coordinator handles all the protocol-specific activity, group liveness, message volume, timing, join traffic, but it never sees an IP, because clients never connect to it directly. They reach it through relays. The relay, in turn, sees the IP but sees only generic ContextVM traffic, with no group IDs, no cordn kinds, no recipients, no operation types. The party that can interpret the traffic cannot locate you, and the party that can locate you cannot interpret the traffic.

That is a structural answer to the article's own strongest threat model, and no relay-based scheme can offer it by construction. It also collapses the filter observability leak: a cordn client's subscription is a generic ContextVM filter to reach a coordinator, not a request for protocol-specific kinds. The relay learns at most that some IP is talking to some ContextVM service, maybe a coordinator or not, and nothing about groups or channels.

It is worth being precise about the observer set too, because this is where Cordn's improvement is categorical rather than marginal. In the public-relay model the observer set is unbounded, persistent, and self-selecting: anyone who cares to subscribe or collect, today or in a year against a stored archive, is an observer forever. In Cordn it is bounded, finite, and chosen: one coordinator, replaceable, and if self-hosted, literally you. The honest one-liner is that it trades a large set of shallow, permanent observers for a small set of deep, chosen ones.

Now the hard part, because I do not want to oversell it, and there are real costs to weigh.

Cordn is the only protocol in this article that runs a service, and on the surface that looks like centralization. It is, partially. A coordinator can observe that a group is active and learn timing and volume patterns for the traffic it handles. It can delay, drop, or censor delivery, so availability trust remains. But it is worth being clear that this is not a new or unique risk introduced by Cordn's model. Every public relay in every other protocol in this article can do exactly the same: observe, delay, drop, or censor. The difference is only who that party is and how many of them there are. The coordinator never sees plaintext, because MLS protects that, and ordinary message posting can use ephemeral transport keys, so it does not even need to learn stable participant identities for routine traffic.

But here is the inversion I want to be precise about. That centralization can also make the system more private, and the reason is that the coordinator holds delivery, not custody. Everything that matters cryptographically, epoch keys, the ratchets, the member tree, KeyPackage secrets, lives client-side on each member's device. The coordinator is a signaling and delivery service, not a state authority. So if a coordinator is compromised, subpoenaed, loses its database, or turns hostile, what is at risk is the backlog of undelivered ciphertext queued there, the pending Welcomes and join requests not yet consumed, and the activity it can observe during the window it is your active coordinator. What is not at risk is the group itself, its membership, its history on members' devices, or the ability to continue. The group survives the coordinator.

And migration is designed in, not emergent. Per-group cursors exist specifically to preserve ordering across a move, which means a group can jump from one coordinator to another because groups do not care which coordinator they live in. It is fair to call that designed-for. The honest caveats are that concurrent multi-coordinator operation is not yet specified, since the protocol is young and intentionally keeps one active write target per group to preserve MLS ordering, that migration loses any backlog you have not drained first, and that migration is recovery, not prevention of harm done during a specific sensitive window. Marmot also keeps MLS secrets local, so secret-custody locality is shared between them. Cordn's specific edge is the migratable ordered delivery point, not the local custody.

There is one more thing that makes Cordn's privacy story practical rather than theoretical. Recent experiments have shown a coordinator that can run from a browser tab, even from a single HTML file you open locally. That turns the ephemeral-coordinator option from a power-user move requiring Docker and a key into something trivial: save a file, open it, talk, close the tab, and there is no server, no logs, no persistent state anywhere. The win is disposability and zero persistent state, not extra network anonymity, since the coordinator still inherits the machine's IP. But disposability is exactly the property you want for a sensitive one-off conversation, and it is the thing no relay-based scheme can ever offer, because relays persist events by design.

So my take on Cordn is that it is the design in this article that takes the central question, can private communication exist over public infrastructure, most seriously. It does not achieve perfect privacy. The coordinator still observes activity, availability trust is real, and the IP decoupling weakens if client and coordinator share relays or against a global active adversary correlating across both layers. But it is the only design willing to abandon the "everything is a public relay event" purity to actually shrink the public-observability surface, and the only one that lets the user choose who the observer is. Its single architectural move neutralizes several observables at once: the protocol fingerprint, the stable routing identifier, the filter leak, and the convergence of IP and protocol visibility. For a lot of threat models that is a more honest and more useful answer than stronger encryption layered over the same observable transport.

Conclusions

So, is private communication over public infrastructure even possible?

After going through all of these approaches, my answer is still: yes, in some sense, but not really, with one important wrinkle that the last design in this article forced me to take seriously.

Every design that keeps its artifacts on public relays, NIP-04, NIP-17, Marmot, Double Ratchet, Concord, Nymchat, leaks enough metadata that I would not call it private communication in the strong sense. They sit at different points in a tradeoff space, and that space has more dimensions than it first appears: content secrecy, forward secrecy, post-compromise recovery, metadata observability, scalability, coordination cost, and the blast radius of a compromised key. Concord is the clearest proof that you cannot collapse that into a single ladder of "better crypto." It deliberately gives up the forward secrecy and post-compromise recovery that Marmot and Double Ratchet provide, in exchange for scalable communities and keyless verifiable authority. That is a legitimate design point, not a failure, but it would be a failure to market it as simply more private.

To make the tradeoff space legible, here is a compact comparison across the axes that actually vary.

Protocol Forward secrecy Post-compromise recovery Relay-visible fingerprint Filter leak Stable routing ID Group scale

NIP-04 No No Protocol-specific (kind 4) High Yes (p) N/A

NIP-17 No No Generic (kind 1059) Medium-high Yes (receiver) N/A

Marmot Yes Yes Protocol-specific (443/445) High Yes (nostr_group_id) Good

Double Ratchet Yes Yes Protocol-specific (1060) High No Poor

Concord No No Protocol-specific (3300 range) High, very legible Yes (z) Good (O(1))

Nymchat Optional (DM only) Soft (rotation) Generic (1059, blends with NIP-17) Low / generic No (rotating keys) O(N) (NIP-17)

Cordn Yes Yes Generic (ContextVM) Low / generic No (coordinator-internal) Good

Read the table as a map, not a ranking. No row wins. Each design pays for its strengths somewhere in another column.

A note on the fingerprint column, which is binary rather than a gradient. I have no anonymity-set measurements to justify ranking one design's traffic as "more" identifiable than another's, so the column only records whether the protocol rides on an event kind specific to it, which makes it trivially recognizable, or a kind shared with other traffic. "Generic" means an anonymity set, not invisibility: NIP-17 and Nymchat blend into the gift-wrap population, and Cordn blends into other ContextVM usage, but once a coordinator's pubkey is known a relay can count exactly how much traffic is addressed to it, so Cordn's effective anonymity set is comparable to gift wraps rather than larger. That is why Cordn sits in the same generic bucket as NIP-17 and Nymchat, not above it.

The one design that genuinely strains my pessimism is Cordn, because it is the only one that stops publishing protocol artifacts to public relays. By moving delivery onto a coordinator reached through general-purpose ContextVM transport, it eliminates the protocol-specific fingerprints every other scheme leaks, removes the stable public routing identifiers, collapses the filter leak to generic traffic, and severs the convergence of IP visibility and protocol visibility. And because that coordinator can be self-hosted, even spun up for a single session in a browser tab and discarded, it turns the observer vantage point into something the user can choose instead of something every adversary on the relay gets for free.

Before I land, I want to interrogate one word that this whole ecosystem, including this article's earlier framing, uses too easily: sovereignty.

Two very different things get conflated under it. Exit sovereignty means you can leave any single relay and find another, and that is what Nostr actually delivers. It is real, and it matters. Control sovereignty means you govern the substrate you depend on, and for public relays nobody has that. The operator has it; you do not. Redundancy across relays buys you exit sovereignty, because it dilutes the chance that any one relay's policy harms you. It does not buy control, and it does not eliminate the class of risk. Over the long term, rate limits, kind restrictions, event flushing, wholesale database wipes, and quietly coordinated behavior across relays all still bite. And as I argued earlier, relays are not passive storage with policies. They are active participants that can delay, drop, reorder, selectively serve stale state, fingerprint you through your filters, or refuse service. Selection among uncontrolled infrastructures is not sovereignty over them.

That distinction lets us say something precise about the field. Almost every protocol here earns authority sovereignty, meaning no company or central server dictates membership or roles, because the crypto verifies client-side. Almost none of them earn transport sovereignty, meaning the ability to run the dissemination you actually depend on. You cannot easily run "the public relay layer" on behalf of your partners. But you can run a coordinator, even from a browser tab. Cordn is the only design in this set where both layers can be sovereign. It is worth being clear about scope too: relays being active adversaries threatens availability and metadata, not content secrecy or authority integrity, which client-side verification protects. Naming that keeps the criticism accurate rather than sweeping.

If there is a lesson across all of these, it is this. The protocols most serious about metadata are exactly the ones willing to give something up to escape the observability trap, whether that is the "everything is a public relay event" purity, or even some cryptographic properties. They do it by keeping custody and state client-side so no intermediary can hold the group hostage, and by making the one remaining trust point small, soft, chosen, self-hostable, and migratable. In other words, by converting an unbounded, persistent, self-selecting observer set into a bounded, disposable, user-controlled one.

That is the real answer to whether private communication over public infrastructure is possible, and it is neither the defeatist "not really" nor a triumphalist "this one wins." Pure public relays are mostly not workable in the strong sense, because relays are unbounded, persistent, active observers you do not control. The designs that escape do so by relocating the observer into something you can run, replace, or discard. If we want to be honest, we cannot collapse all of that into the word private and move on.

I intentionally kept this piece focused on privacy rather than UX, even though the two constantly touch each other. But it is hard to read through these protocols without noticing that better secrecy and a better privacy posture often come with costs in complexity, spam resistance, coordination, recoverability, or general usability.

Encrypted is not the same as private. Public infrastructure is not a neutral carrier. And if we want private communications on top of public systems, we have to be far more demanding about metadata, far more honest about tradeoffs, and far more precise in the claims we make.

Protocol	Forward secrecy	Post-compromise recovery	Relay-visible fingerprint	Filter leak	Stable routing ID	Group scale
NIP-04	No	No	Protocol-specific (kind 4)	High	Yes (`p`)	N/A
NIP-17	No	No	Generic (kind 1059)	Medium-high	Yes (receiver)	N/A
Marmot	Yes	Yes	Protocol-specific (443/445)	High	Yes (`nostr_group_id`)	Good
Double Ratchet	Yes	Yes	Protocol-specific (1060)	High	No	Poor
Concord	No	No	Protocol-specific (3300 range)	High, very legible	Yes (`z`)	Good (O(1))
Nymchat	Optional (DM only)	Soft (rotation)	Generic (1059, blends with NIP-17)	Low / generic	No (rotating keys)	O(N) (NIP-17)
Cordn	Yes	Yes	Generic (ContextVM)	Low / generic	No (coordinator-internal)	Good

Oh wow, @npub1m4n…c2jl ! Thank you so much for such a fat zap! ...

2026-06-25T09:34:43Z

Oh wow, Laeserin (npub1m4n…c2jl) ! Thank you so much for such a fat zap! Really appreciate it :)
That will keep our public coordinator running for months 🫶

What about Nymchat.app from @npub16jd…33sv ?

2026-06-24T21:06:03Z

In reply to nevent1q…uf0m
_________________________

What about Nymchat.app from Luxas (npub16jd…33sv) ?

📢 Cordn now has a News & updates feed, release notes, new ...

2026-06-24T14:56:36Z

📢 Cordn now has a News & updates feed, release notes, new features, and product updates, all in one place inside the chat app.

💛 Cordn is free and open source so we added a donation card as well and a 'Supporters' section. Tap Donate to send us a Lightning zap. The supporters list lives right there in the feed.

This is just the beginning, follow along as Cordn keeps evolving.

🔗 https://cordn.net/chat/news

#Cordn #OpenSource #MLS #Privacy

I'm using it, pretty good model tbh

2026-06-24T13:27:15Z

In reply to nevent1q…3j2r
_________________________

I'm using it, pretty good model tbh

Nostr event nevent1qqsdjgcqpdlaf26zp4wyxnsxspqn4nmjuz24q6sls44u0494fdzgewqzyqrqursntk7h265qhxrf9jgzfzmgd4j4tpkrrzw2us6sk2xj0m5tuj3dhtl

2026-06-24T07:27:13Z

Good morning nostr. Ready to rock!

Brother what in earth! This is powerful 🔥🤯 #nevent1q…7w22

2026-06-23T15:41:43Z

Brother what in earth! This is powerful 🔥🤯

quoting
nevent1q…7w22
Man, this is crazy. An MLS coordinator that runs in a browser tab 👀, allowing really private communications without hassle, no need for a server to deploy it. One of the most cypherpunk things I’ve seen in a while.
Of course, this has some limitations, like if you close the tab, the coordinator goes offline. But that’s indeed a feature, not a bug. Ephemeral coordinators that exist only for as long as you need them online. You could also persist the coordinator’s public key so it survives refreshes. This could truly bring back the good ol' days when you chose to be online instead of being always connected. You’re online only when your coordinator is online. Beautiful. No spoofers. No one can shut you down. Plus, the page is static, so you could easily save it and run it from an HTML file 🤯🤯🤯
nevent1q…xmdj

Hello Nostr! How's it going? Are you using Cordn already, or ...

2026-06-19T09:25:34Z

Hello Nostr! How's it going? Are you using Cordn already, or just pretending your comms are private?

We broke it! Hahaha. The stress test group got corrupted, but ...

2026-06-13T17:39:59Z

We broke it! Hahaha. The stress test group got corrupted, but this is good news, we identified why it happened and implemented some hardening strategies to avoid MLS state corruption. This is a win; now our app is more robust. We’re creating stress test v2, so please feel free to join and see if we can break it again! :)
https://cordn.net/chat/7960e471-22ad-40db-b0de-0d46fde708e8?m=eyJuYW1lIjoiU3RyZXNzIHRlc3QgdjIiLCJpY29uIjoi8J%2BMtCJ9

quoting
nevent1q…z7u9
New Cordn feature: Shareable group links 🔗

We've just added join requests for groups to the Cordn coordinator, the web client, and the CLI client. This means you can share a link so anyone who isn't yet a member can request to join a group.

Try it now: join our stress test group 👇
https://cordn.net/chat/b530f14c-fd6b-4023-8001-cebcdfbfb239?m=eyJuYW1lIjoiU3RyZXNzIFRlc3QiLCJpY29uIjoi8J%2BMsiJ9

Here's how it works: When a user request to join a group, a join request lands as a notification for the group admins. Any admin approves, the user receives an invitation and gets added, done. If the user doesn't have an account yet, they're prompted to log in and everything resolves transparently, no extra steps. It's the perfect onboarding tool. Share links out of band, drop them in public channels, simple and intuitive.

Read the spec: https://github.com/Cordn-msg/cordn/blob/master/spec/applications/join-requests.md

This feature also kicked off a new section in the Cordn specs: application specs. Rather than extending the core spec for every new feature, app specs are separate documents for ongoing development, research, and enhancements. They keep the core spec stable while giving new ideas room to breathe and evolve.

https://github.com/Cordn-msg/cordn/tree/master/spec/applications

We're building Cordn as best we can, a project born out of love, with zero funding. If you like what we're doing, consider zapping me or contributing. Code, bug reports, ideas, everything helps.

Shoutout to Joel 🇨🇭 (npub12w5…rrm3) for their first contribution to the web client, enhancing the login dialog. 🫶

Now go play. https://cordn.net is free, private, and needs no email, phone number, or KYC. Speak freely. No one can listen.

New Cordn feature: Shareable group links 🔗 We've just ...

2026-06-11T15:28:15Z

New Cordn feature: Shareable group links 🔗

We've just added join requests for groups to the Cordn coordinator, the web client, and the CLI client. This means you can share a link so anyone who isn't yet a member can request to join a group.

Try it now: join our stress test group 👇
https://cordn.net/chat/b530f14c-fd6b-4023-8001-cebcdfbfb239?m=eyJuYW1lIjoiU3RyZXNzIFRlc3QiLCJpY29uIjoi8J%2BMsiJ9

Here's how it works: When a user request to join a group, a join request lands as a notification for the group admins. Any admin approves, the user receives an invitation and gets added, done. If the user doesn't have an account yet, they're prompted to log in and everything resolves transparently, no extra steps. It's the perfect onboarding tool. Share links out of band, drop them in public channels, simple and intuitive.

Read the spec: https://github.com/Cordn-msg/cordn/blob/master/spec/applications/join-requests.md

This feature also kicked off a new section in the Cordn specs: application specs. Rather than extending the core spec for every new feature, app specs are separate documents for ongoing development, research, and enhancements. They keep the core spec stable while giving new ideas room to breathe and evolve.

https://github.com/Cordn-msg/cordn/tree/master/spec/applications

We're building Cordn as best we can, a project born out of love, with zero funding. If you like what we're doing, consider zapping me or contributing. Code, bug reports, ideas, everything helps.

Shoutout to Joel 🇨🇭 (npub12w5…rrm3) for their first contribution to the web client, enhancing the login dialog. 🫶

Now go play. https://cordn.net is free, private, and needs no email, phone number, or KYC. Speak freely. No one can listen.

Just pushed some updates to the Cordn web app. This time around, ...

2026-06-10T16:20:00Z

Just pushed some updates to the Cordn web app. This time around, there are some minor UI/UX improvements.

- Added a new chat action button to start a conversation that lets you create a group or just start a chat with someone.

- Made the action icons a hamburger menu when the sidebar is collapsed (desktop).

- Improved loading states and other minor enhancements.

Enjoy!

Thanks man! appreciated it! I'll add you to the dev group so ...

2026-06-10T07:42:37Z

In reply to nevent1q…e4qp
_________________________

Thanks man! appreciated it! I'll add you to the dev group so you can share ideas, issues and other stuff and help to build this :)

Great! thanks for testing

2026-06-10T07:41:24Z

In reply to nevent1q…j39h
_________________________

Great! thanks for testing