Nostr notes by Gzuuus

Gm

2026-10-28T09:14:50Z

In reply to nevent1q…agq8
_________________________

Gm

https://www.youtube.com/watch?v=uuKOXGVIP8I

2026-10-27T15:21:15Z

https://www.youtube.com/watch?v=uuKOXGVIP8I

Nostr event nevent1qqsy32eeu38dzln9v8jlynf9g8qvtp60ps0h0lqmr2fpgcfpelpf2sszypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zzefxs7

2026-10-26T17:21:07Z

Nostr event nevent1qqsx7eldzcg8gpx8d57dxmyyy5fkeawqac6w3n26l7dzhwkvndwn5kqzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zm0jggk

2026-10-26T16:57:53Z

Nostr event nevent1qqs2x3qdszd2j7wpf2ady88qh6de6jmrywq8tyc8q2t9s3m43amqx7qzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z2nuhfs

2026-10-23T20:54:14Z

quoting
nevent1q…wv9y
⚡️🤖 TECH - Anthropic just killed the REA

It stops claude from doing it
That’s why local models are important

... My kind of humor ...

2026-10-22T14:37:34Z

... My kind of humor

Ngu tech #nevent1q…pjna

2026-10-22T10:09:51Z

Ngu tech

quoting
nevent1q…pjna
https://cve.0xosprey.com/

But being honest just Pretty Hysteric People #nevent1q…66tl

2026-10-21T20:45:58Z

But being honest just Pretty Hysteric People

quoting
nevent1q…66tl
Pretty Hopeful People

Nostr event nevent1qqsr63u07e8k0kcptylrp8gvnvda898d2mhlcnre34hdspp6kdz7fxqzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z3wwuc5

2026-10-21T20:40:45Z

Pretty Hopeful People

Hahaha these vids are amazing

2026-10-21T20:34:33Z

In reply to nevent1q…hd7n
_________________________

Hahaha these vids are amazing

Nostr event nevent1qqstuzmxev02dvukhk947v8ms3xgh96nw97quy03jvhjfprchpfy7zszypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zgxwxmr

2026-10-21T10:51:18Z

quoting
nevent1q…8v9m
This is crazy... Wild times ahead
https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/

This is crazy... Wild times ahead ...

2026-10-21T10:31:31Z

This is crazy... Wild times ahead
https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/

Nostr event nevent1qqs8fwhk0w7t3686h2547ad2kdm2llzg0svpm65300ajjv5ll20xkvczypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z4yhddv

2026-10-21T09:43:00Z

Nostr event nevent1qqsgckauwfutzv2j720x906zvegnxge5lwh27zr6n39wzeqtgwgkepczypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zzd24yq

2026-10-20T14:26:09Z

Tbh I was testing in my phone and didn't had to much time, it ...

2026-10-20T14:12:59Z

In reply to nevent1q…ycfw
_________________________

Tbh I was testing in my phone and didn't had to much time, it didn't timed out tho, just kept spinning and then I had to move, was waiting for more or less 2 mins

LFG! Looking forward for this

2026-10-20T14:07:28Z

In reply to nevent1q…r77a
_________________________

LFG! Looking forward for this

LFG!

2026-10-20T14:06:12Z

In reply to nevent1q…42wl
_________________________

LFG!

https://music.youtube.com/watch?v=RqckEWeHGgg

2026-10-20T13:52:36Z

https://music.youtube.com/watch?v=RqckEWeHGgg

Did many successful tool calls, but got stuck at getrawmempool

2026-10-20T11:13:23Z

In reply to nevent1q…j4gq
_________________________

Did many successful tool calls, but got stuck at getrawmempool

Seems he got his arm damaged in the simulation

2026-10-20T10:41:48Z

In reply to nevent1q…sfxt
_________________________

Seems he got his arm damaged in the simulation

GM dany trejo

2026-10-20T10:39:21Z

In reply to nevent1q…qt0s
_________________________

GM dany trejo

Nostr event nevent1qqstqkqmjynzlnyrqmzwt7020yrwheyn7gkm2yqpltufc0uxs95kjrszypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z6cgg2s

2026-10-20T08:44:45Z

GM!

Nostr event nevent1qqsghz2vk7ljnr73xfdj3kxp5r8gwjrfdrgs07f9jz6eafscgxedy7qzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zfcedf8

2026-10-19T20:44:46Z

GM Quiche eaters ...

2026-10-19T09:07:17Z

GM Quiche eaters

It's fri https://music.youtube.com/watch?v=c3P3lKFqYYM

2026-10-16T16:24:24Z

It's fri
https://music.youtube.com/watch?v=c3P3lKFqYYM

I wish... xD

2026-10-16T15:01:42Z

In reply to nevent1q…e82l
_________________________

I wish... xD

Nostr event nevent1qqsva2ltr7v92kj87drreuvusannscp5f2ks7fzgghkpttc36hxjyfczypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69ze5asek

2026-10-16T14:56:58Z

progressively wiseless

Defo not satisfying real hunger xD ...

2026-10-16T08:56:09Z

Defo not satisfying real hunger xD

Nostr event nevent1qqsdmnyvd582quzx99j68dl3stspyg8qdc2sp3nxp64yue9hvg9fgqszypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zxf4puc

2026-10-15T14:25:58Z

Gradient descent

2026-10-15T10:04:13Z

In reply to nevent1q…kfwh
_________________________

Gradient descent

Hahaha this is funny, that's my terminal window btw, the ...

2026-10-15T09:10:16Z

Hahaha this is funny, that's my terminal window btw, the skipped verifying randomness with a die roll, trust me bro line is sublime

GM 🌞 lately I'm developing the habit of just as I wake up ...

2026-10-15T08:17:07Z

GM 🌞 lately I'm developing the habit of just as I wake up sit in my bed and meditate, thinking about the things I feel grateful for, and every day I find new things to be grateful for, everyday is a gift, we tend to forget that
https://music.youtube.com/watch?v=68XSuahPw-k

Nostr event nevent1qqsyv5sc93qdktj8y8p022xtgf9gknhyutjm5jaf088kexxhqy8upkgzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zwd8uxj

2026-10-14T08:16:35Z

Gf*M

Nostr event nevent1qqsfvr229jgws4kf5hu7zxldmct9w85tpeu2a69u53yuv2y2luwqtggzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z3w7ggt

2026-10-13T16:05:23Z

I assume peas hahaha

2026-10-13T13:15:15Z

In reply to nevent1q…tuxl
_________________________

I assume peas hahaha

Is there any possible answer? Hahaha

2026-10-13T12:57:48Z

In reply to nevent1q…3tlx
_________________________

Is there any possible answer? Hahaha

It's a peaceful life ...

2026-10-13T12:06:48Z

It's a peaceful life

Lmfao reddit is an special place... ...

2026-10-13T10:43:19Z

Lmfao reddit is an special place...

Nostr event nevent1qqszvklwaz0kmrlx5n8t8tj36h7j5degxwc3d0wgrdan2ny87zwtx3czypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zumuql5

2026-10-12T09:52:06Z

Kindof

2026-10-12T08:34:03Z

In reply to nevent1q…zk2e
_________________________

Kindof

Nostr event nevent1qqspq95pd5hujr3tjx4k5vwhraeyhv53dwjrkmcjeyzrljauryu0hngzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z3fy2uv

2026-10-11T21:00:37Z

In reply to nevent1q…9hf7
_________________________

https://en.wikipedia.org/wiki/Sycophancy_(artificial_intelligence)

Nostr event nevent1qqsrj9nvkvz856kyeqc3yjlekeppz4g73zmmc0cqv5leya8ds8axlkgzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zc2uxvg

2026-10-11T18:37:48Z

Sycophancy is real

GM 🫶

2026-10-11T09:26:59Z

In reply to nevent1q…jd7z
_________________________

GM 🫶

Will print this note and hang it on my wall 🔥

2026-10-10T11:11:43Z

In reply to nevent1q…wlgf
_________________________

Will print this note and hang it on my wall 🔥

Man this is hilariously painful xDD

2026-10-09T15:08:26Z

In reply to nevent1q…ae3z
_________________________

Man this is hilariously painful xDD

Oh yea... Sure they will expose it... XD crazy times

2026-10-09T08:18:10Z

In reply to nevent1q…msvq
_________________________

Oh yea... Sure they will expose it... XD crazy times

Incredible the level of face washing just after few years this ...

2026-10-09T07:48:07Z

Incredible the level of face washing just after few years this happened... Incredible 🤮

quoting
nevent1q…nxyv
⚡️🎥 END OF DAY - The Netflix series about the FTX fiasco and SBF's shenanigans premieres on November 19.

“The Altruists”: Will you be watching it?

I'm not surprised 😅

2026-10-08T16:06:48Z

In reply to nevent1q…9tnt
_________________________

I'm not surprised 😅

Maths ⚔️ slop ...

2026-10-08T15:02:34Z

Maths ⚔️ slop

GM 🫶

2026-10-08T14:59:38Z

In reply to nevent1q…xs00
_________________________

GM 🫶

https://www.youtube.com/shorts/AYQhWSSHrFY

2026-10-08T14:59:27Z

https://www.youtube.com/shorts/AYQhWSSHrFY

Great day 🌞 ...

2026-10-08T14:46:08Z

Great day 🌞

You're giant 🫶

2026-10-08T14:33:31Z

In reply to nevent1q…nxpv
_________________________

You're giant 🫶

Nostr event nevent1qqsqqqygq32vj6kmumjm6439fvn09ypc2ef67ldfjlerwc669w6es3gzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z32wq50

2026-10-08T08:06:21Z

This feels like vegan meat

2026-10-08T07:49:20Z

In reply to nevent1q…q7uy
_________________________

This feels like vegan meat

I think @nprofile…udid it already?

2026-10-07T21:14:19Z

In reply to nevent1q…ja3n
_________________________

I think nprofile1qqs982g78fjdrajcaxp6c8j0ncxxjlu0x0spmr0tusulfsdfyyfltysl4vr5udid (nprofile…udid) it already?

GIFs! 🔥 #nevent1q…wdkn

2026-10-07T16:35:44Z

GIFs! 🔥

quoting
nevent1q…wdkn
When you cannot find the words, say it with a GIF :)
nevent1q…9hdn

Man stop using my gms for quoting this crazy notes, I don't ...

2026-10-07T08:51:56Z

In reply to nevent1q…trrf
_________________________

Man stop using my gms for quoting this crazy notes, I don't like it tbh

GM #nevent1q…48dp

2026-10-07T08:36:23Z

quoting
nevent1q…48dp

Very cool 👀

2026-10-07T08:35:39Z

In reply to nevent1q…0thk
_________________________

Very cool 👀

Red wine. I'm testing different flavors. Peach is pretty good

2026-10-06T16:19:49Z

In reply to nevent1q…k2ul
_________________________

Red wine. I'm testing different flavors. Peach is pretty good

Hahaha they are happier now

2026-10-06T16:19:14Z

In reply to nevent1q…pj7n
_________________________

Hahaha they are happier now

No, it makes you stronger

2026-10-06T16:14:55Z

In reply to nevent1q…s392
_________________________

No, it makes you stronger

Mixing wine and kombucha. I'm calling it kombolutxa, like ...

2026-10-06T15:55:05Z

Mixing wine and kombucha. I'm calling it kombolutxa, like kalimotxo but with kombucha... Delicious 👌

Why are you quoting me like this?

2026-10-06T09:32:34Z

In reply to nevent1q…w4x8
_________________________

Why are you quoting me like this?

Nostr event nevent1qqsqqqphla98jtp8dxmvpe3pvkhhuqqphxcu635w57288j8337dlqcqzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zqgps84

2026-10-06T08:55:18Z

GM 🖖

Massive! Amethyst supporting Cordn 🔥 Little by little, the ...

2026-10-05T20:18:05Z

Massive! Amethyst supporting Cordn 🔥 Little by little, the protocol is adding compatible clients. So far, this is the 4th one, if I recall correctly. There’s the official Cordn client, web, Android, and CLI (especially good for clankers); cahmls by sandwich (nprofile…gw67) , which implements a client together with a coordinator you can run in a browser tab; staircase by cloud fodder (nprofile…g4gy) , which is already pretty powerful and well maintained; and now Amethyst. LFG 🔥🔥🔥

quoting
nevent1q…l7vx
#Amethyst v1.17.0: Cordn, Geocaching, a New QR Scanner, and One UI

Highlights:

- Adds **Cordn** group chats: MLS groups over an MCP coordinator, with the
full chat experience, device migration and encrypted backups.
- Adds **Geocaching** (NIP-CC): a hub, a map, hunts, and QR-verified finds.
- Rebuilds the **QR scanner** on CameraX + zxing-cpp. It reads off-axis, blurry
and low-contrast codes the old one could not.
- Brings **Concord** up to spec: pins, Direct Invites, private channels with key
rotation, disappearing messages, kick and dissolve.
- Brings the **in-app browser** close to an installed Chrome PWA, with a new
omnibox and a search-engine setting.
- Shows **Ultra HDR** photos, plays **audio posts** as cards with
picture-in-picture, and shares what you listen to as **Now Playing**.
- Asks before another app's version of your **backed-up lists** drops items.
- Moves ~200 screens into shared UI on the way to **one UI** for Android and
Desktop.

## New Features

### Cordn

- Adds Cordn group chats to the Messages inbox, beside DMs, Marmot and Concord.
Messages never enter the event cache, so they are never searchable.
- Builds the chat on the shared components: bubbles, gestures, reactions,
quoted replies, day and unread dividers, and the rich text renderer.
- Adds replies, reactions, edits, deletions and pins, interoperable with the
reference client. Pins sit in a one-line carousel above the chat.
- Uses the shared composer: @-mentions, emoji shortcodes, GIF keyboard and paste.
- Adds encrypted attachments over Blossom and encrypted voice notes, with the
shared upload dialog and media viewer.
- Keeps drafts, unread counts and messages on disk, so rooms no longer open
empty after a relaunch.
- Redesigns New group as four steps: name, people, coordinator, and who can
add and remove. Shows how many of your people each coordinator can reach.
- Invites the whole roster in one commit, so one failed invite cannot fork the
group. People without a key package get a share link instead.
- Finds coordinators from their ContextVM announcements and names them by
profile, instead of asking for a 64-character key.
- Adds member management: add by name, npub or NIP-05, remove, rename, and admin
mode. Enforces admin rights like the reference client.
- Adds a metadata-exposure card explaining what each coordinator can learn.
- Shares groups as `cordn1…` links and QR codes, and adds an invitations screen
with Join and Decline.
- Adds join requests, coordinator health and management, and a key-package
screen that keeps your pool topped up.
- Adds device migration: the old phone shows a handoff code, the new phone scans
it and restores every group with its history. Keys are never in the code.
- Adds encrypted backup and restore of groups and their messages.
- Groups all Cordn settings under one entry, and adds Cordn Groups to the drawer
and the bottom-bar catalog.

### Geocaching (NIP-CC)

- Renders geocache listings and found logs as cards, with a photo hero, map
inset, rating, distance and badges.
- Adds a Geocaches hub (Nearby, Map, Hunts, Finds, Mine), cache details with
their log thread, and composers for caches, hunts and logs.
- Verifies a find by scanning the cache's QR code. The secret signs once and is
never stored.
- Hides hints behind a tap, and detects whether each was written in plaintext
or ROT13.
- Sorts Nearby by distance only when you ask.
- Opens caches and hunts from feeds, notifications, `naddr` links, QR scans and
search.

### QR Codes

- Rebuilds the scanner on CameraX + zxing-cpp, with autofocus, tap-to-focus,
pinch zoom and a torch. The old decoder read 31 of 48 test codes.
- Lets you pick when several codes are in frame or in a picture, and reassembles
multi-part codes.
- Reads codes from the gallery, the clipboard and the share sheet, and adds a
"Scan QR code" launcher shortcut.
- Explains a code it cannot open instead of closing, and keeps private keys off
the result screen and out of the logs.
- Keeps the screen bright while showing your own QR code.

### Concord

- Adds pinned messages, with a pin badge in the channel header and
jump-to-message.
- Adds Direct Invites: invite by npub, and accept or decline from the hub,
Notifications or Messages.
- Adds Public and Private community modes. A ban in a Private community rotates
the keys.
- Adds private channels, with Make private, Make public and Rotate key.
- Adds disappearing messages, with a timer from 1 day to 1 year.
- Adds cooperative Kick and community dissolution.
- Moves the Community List to the fragmented kind 33302, migrating the old list.
- Lets you edit your own thread replies and retract a reaction by tapping it
again.
- Shows the community description at the top of the channel list.

### Marmot

- Adds editing your own messages, compatible with White Noise edits.
- Detects a group this device has fallen out of sync with, and offers a Reset
that keeps history.
- Names unnamed groups after their members, and hides names on bubbles in
two-person groups, like DMs.
- Commits a member's leave automatically when you are an admin.
- Applies White Noise admin deletions.
- Adds Marmot Groups to the drawer, and makes the list read like the DM list.
- Warns when another device of yours is receiving your invites, and offers to
move them here.

### Buzz

- Brings Buzz to parity with upstream: artifacts, huddle liveness, team catalog,
projects and thread windows.
- Writes channel messages as kind 9, as Buzz's own clients do, and lets you edit
them.
- Labels agents as "Agent · managed by Alice", and tells apart members with the
same name.

### Browser

- Brings the in-app browser close to an installed Chrome PWA: new windows,
Tor-aware downloads, fullscreen, find in page, text size, desktop site and
crash recovery.
- Redraws every browser surface with one shared pill.
- Reworks the address field into an omnibox with paste-and-go and completions.
- Adds a search-engine setting: DuckDuckGo, Brave, Startpage, Mojeek, Qwant,
Ecosia, Kagi, Google or Bing.
- Adds per-site camera, microphone and location permissions, with "Only this
time".
- Adds "Add to Home screen". Shortcuts open in Amethyst and wait for Tor.
- Shows page alerts and prompts, which used to be silently cancelled.
- Replaces the WebView error page with a readable one, with Try again and Try
without Tor.
- Asks before every download, with the real name, size and source, and blocks
files pretending to be another type.

### Media

- Shows Ultra HDR photos in HDR, capped at 2x in the feed.
- Plays audio files in posts as a waveform or cover card, with
picture-in-picture.
- Shares what you are listening to as a NIP-38 music status, from Amethyst,
other apps or desktop players. Off by default.
- Adds captions to NIP-71 videos, with a CC toggle in the player.
- Shows video credits, and checks collaborators who accepted.
- Plays divine.video's adaptive HLS streams.
- Adds Cast on Android 17, and names the format a receiver refuses.

### Backups

- Asks before another app's version of your follows, mutes, relays, profile,
wallets or settings drops items you backed up.
- Shows a card on Home for each conflict, with one-tap Accept.
- Adds a review screen per conflict that lists every removed, added and changed
entry.
- Keeps open conflicts across restarts, and closes them when the other app puts
the items back.

### Key Backup

- Shows the nsec as a numbered, grouped grid you can copy onto paper. It hides
again when the app goes to the background.
- Adds a confirm-then-encrypt flow for the ncryptsec backup.
- Requires passwords of at least 12 characters for new ncryptsecs. Old ones
still open.
- Accepts hand-typed keys at login, with uppercase letters, spaces or dashes.

### Profiles

- Reads NIP-92 `imeta` for profile pictures and banners, trying the declared
fallback URLs when the main one fails.
- Shows the banner's blurhash while it loads.
- Publishes an `imeta` for freshly uploaded pictures and banners, on Android and
Desktop.

### Signing

- Shows a relay login (kind 22242) as a login card in signing prompts, naming
each relay exactly as signed. Odd-looking addresses get a "check before
signing" warning.
- Makes the event preview in signing prompts read-only, so you can no longer
react, zap, vote or RSVP on an event that does not exist yet.

### Notifications

- Shows DMs, Marmot groups and Buzz rooms as Android conversations, with
per-chat priority and launcher shortcuts.
- Shows inline-reply progress, with a Retry that keeps your text.

### Calendar

- Shows follows' "Going" RSVPs on Home, with a toggle in Settings.
- Adds a "Friends going" lens of upcoming events your list attends.

### Feeds and Lists

- Renders 3D Simple Nostr Objects, shards and cyberspace avatars, with a
full-screen viewer.
- Opens cyberspace region bags, showing how long the search will take.
- Renders every NIP-51 list kind as a card, instead of encrypted text.
- Adds favorite follow sets: star any follow set to use it as a feed.
- Shows prediction markets and ballots as their own cards, and hides kind-38000
spam.
- Shows Zapstore app curation sets, NIP-34 git status events and video curation
lists as cards.
- Shows a compact link preview for pages without an OpenGraph image.
- Shows follow-list petnames as a display-name fallback.
- Adds Cash App, Nano, Revolut, silent payments and BIP-353 payment targets.

### Messages

- Redesigns the Messages list: unread drives emphasis, and previews show @Name or
"Photo" instead of raw links.
- Redesigns the chat screen: softer bubbles, clock times and the avatar outside
the bubble.
- Shows sent messages immediately with a sending state, and retries a failed
send on tap.
- Plays voice messages and encrypted audio in the waveform player.
- Shows a DM rename as "Alice renamed the conversation".

### Uploads

- Falls back through your Blossom servers when an upload fails. The signer is
asked once.
- Shows why an upload failed, and lets you remove a failed attachment.

### Relays

- Adds an event allow list, roles and claims to relay management (NIP-86).
- Detects when a NIP-29 group has moved to another relay, and supports group
banners and `a` pins.

### Android

- Enables ARM Memory Tagging on supporting devices to catch native memory bugs.

## Performance

- Loads My Fitness progressively instead of behind a 2–3s spinner.
- Cuts the DEX from 31.1 MB to 29.9 MB by dropping kotlin-reflect.
- Confirms a Marmot group change at the first relay that accepts it, so creating
a group no longer waits for the slowest relay.
- Stops the Marmot key-package lookup shortly after the first package arrives, so
adding a member no longer takes most of a minute.
- Stops rewriting the whole Marmot message log and group state on every send.
- Removes a duplicate encryption on every Marmot send.
- Loads cached Blossom images straight from disk, also offline.
- Remembers missing Blossom files for 30s, so videos no longer stall 10s per
retry.
- Makes the audio visualizer smooth: 46 frames a second instead of 5.
- Speeds up the 3D renderer 4x and cuts its GC from 51% of a core to 7.7%.
- Speeds up the event cache's list observers 1.3–4x.
- Stops calendar screens rescanning the cache on every event.
- Stops the fullscreen image dialog recomposing on every frame of a swipe.
- Stops rebuilding Notifications and Messages on every Concord update.

## Improvements and Bug fixes

- Shows Tor status in the drawer. The icon hides when Tor is off and opens Tor
settings on tap.
- Fixes devices stuck on "Loading account" forever because they reject the
AES/GCM/PKCS7Padding cipher.
- Fixes encrypted stores that could write but not read back.
- Moves settings and account data from SharedPreferences to DataStore, and keys
off the deprecated androidx.security. Old files stay for downgrades.
- Fixes Tor never working on 32-bit ARM and x86 devices, which shipped without
the Tor library.
- Fixes notifications opening on a black screen after a cold start.
- Opens DM and private reply notifications in their conversation, under the
right account.
- Fixes kind-5 deletions matching any author: one user could hide another's
note.
- Decrypts private zaps for the zapped user, showing the real zapper.
- Fixes zap goals reading only 0% or 100%.
- Saves Cashu counters before using them, so a crash cannot lock funds at the
mint.
- Keeps proof-of-work posts mining in the background, and saves the draft first.
- Fetches your own profile and lists from inbox relays when you have no write
relays.
- Fits subscriptions under a relay's filter cap instead of losing the whole REQ.
- Keeps a subscription alive when a relay refuses one kind by name.
- Splits large profile requests, so relays that cap results do not leave authors
unnamed.
- Fixes quoted notes stuck on "Loading quoted note...".
- Sends calendar RSVPs to the host's and every invitee's inbox relays.
- Keeps the calendar's view and scroll when you come back to it, and stops
appointments flickering.
- Fixes Marmot groups forking on relay echoes, simultaneous commits, and
commits that leave you alone.
- Sends Marmot reactions and deletions inside the group, so White Noise sees
them.
- Fixes Concord messages being invisible in Accordion and other applesauce
clients.
- Fixes Concord joins: channels show at once, and failures are reported.
- Keeps a private channel's old keys, so history survives a rotation.
- Lets a banned Concord member return when re-invited after an unban.
- Fixes Direct Invites that never arrived.
- Fixes Buzz Desktop interop: uploads, mentions, profile, and relay refusal
reasons.
- Shows Buzz Join only to non-members and Leave only to members.
- Keeps browser pages on Tor whenever any surface uses Tor, and fails closed
when Tor cannot be applied.
- Keeps NIP-07 replies with the page that asked, and holds signing and payments
from tabs you are not looking at.
- Brings back black browser tabs and restores the page after Android reclaims
memory.
- Stops deleting a private DM from publishing a public NIP-09.
- Fixes NIP-49 rejecting some valid keys and crashing on very high scrypt costs.
- Plays videos from a local Blossom cache over Tor, and falls back to the server
when the cache is closed.
- Restores YouTube link previews.
- Stops the keyboard staying up after leaving a text field.
- Keeps the bottom bar on every pinnable tab.
- Returns a tablet rail tap to that tab's root.
- Makes all floating action buttons circular.
- Fixes amounts rounding wrongly, such as 12,500 showing as "12k".
- Fixes "100%%" in relay uptime labels.
- Fixes NWC notifications for wallets on the new NIP-47 extensions spec.
- Shows the bunker's error when a NIP-46 signer refuses.
- Encrypts every private relay entry, including ones other clients left in
plain text.
- Uses plurals for counts, so Czech and Polish read correctly.
- Fixes two release-only crashes on launch in the minified build.

## Desktop

- Stops offline users being stuck on "Connecting to Tor...": after 10s it offers
a regular connection.
- Reads now-playing from Linux MPRIS, macOS Spotify and Music, and Windows media
controls.
- Shows names and avatars for thread replies, and stops holding every note in
memory.
- Shows the nsec in the hand-copyable grid, and requires 12-character passwords.
- Uses the shared report dialog, which now also mutes the author.
- Renames the AppImage to `amethyst-desktop--.AppImage`.

## Cli

- Adds `amy cordn` for refs, exposure, coordinators, key packages, groups,
invites, sending, `watch` and `migrate`.
- Adds `amy sno` to validate 3D objects and avatar proof of work.
- Adds `amy cyberspace`, which matches the reference cyberspace-cli.
- Adds `amy concord` pins, invites, private channels, kick, dissolve and timer.
- Adds `amy admin` commands for NIP-86 allow lists, roles and claims.
- Adds `amy relaygroup pin/unpin` and joins from invite links.
- Catches up correctly on Marmot groups after being offline.
- Accepts hand-copied keys in `amy login` and `amy key decrypt`.

## Quartz

- Adds ContextVM (MCP over Nostr) with all 12 CEPs, and the Cordn protocol.
- Moves the MLS engine to `quartz/mls/`, shared by Marmot and Cordn, with
several RFC 9420 interop fixes.
- Adds NIP-CC geocaching, Simple Nostr Objects, cyberspace region bags and
Tapestry Decentralized Lists.
- Adds NIP-FE relay commands over HTTP, with a client and a server.
- Adds NIP-67 EOSE completeness hints and a NIP-43 membership engine.
- Follows the latest NIP-29, NIP-47, NIP-51, NIP-86 and NIP-A3.
- Fixes NIP-44 padding above 16 MB and rejects non-canonical lengths.
- Fixes NIP-49 to check the AEAD tag and zero derived keys.
- Fixes NIP-88 rejecting every spec-conformant `polltype` tag.
- Fixes NIP-62 vanish requests for relays without a trailing slash.
- Stops page limits truncating NIP-77 negentropy reconciles.
- Answers a superseded replaceable with `OK false replaced:`.
- Indexes every natural-language tag on Decentralized Lists, so authors and
subjects become searchable, while skipping URLs and ids. Indexed text drops
from 105 MB to 75 MB on 1.5M events. Existing databases need
`reindexFullTextSearch()`.
- Makes local search match a searchable kind only by what it indexes, so local
and store search agree.
- Adds typed diffs between versions of replaceable events.
- Fixes many tag readers and bounds checks on hostile tags.
- Renames event classes to their NIP names, keeping deprecated aliases.
- Breaking: removes `ForkTag`. Use `experimental.forks.parseForkedAddress`.
- Fixes iOS ConcurrentModificationException crashes in LargeCache.

## Geode

- Serves NIP-FE relay commands over HTTP, with limits, CORS and NIP-98 sign-in.
- Adds NIP-43 membership: members-only writes, invites and roles.

## Build & Documentation

- Enables R8 obfuscation, and publishes mapping files with each release.
- Adds `scripts/retrace.sh` to deobfuscate a crash report in one command.
- Checks at release time that every reflected class survived R8.
- Builds Arti and zxing-cpp reproducibly for all four ABIs.
- Moves 1,906 strings to shared Compose resources.
- Moves the event cache, Account, AccountViewModel and most screens into
`commons`/`commonsUI`. 204 of 252 screens are now shared.
- Makes `./gradlew test` run every KMP module's JVM tests: 11,690 instead of
3,567.
- Updates AGP to 9.4.1, Gradle to 9.8.0, Compose Multiplatform to 1.12.1, Ktor
to 3.6.0, Coil to 3.6.3 and zoomable to 2.16.0.
- Runs Android Lint in its own CI job.
- Bumps `appCode` to 462.

## Contributors

- VitorPamplona (nprofile…vhl6)
- ⚡ Dee Kay ⚡ (nprofile…m3sx)
- cloud fodder (nprofile…7nrg)
- Jameson Lopp (nprofile…xxx2)
- atesfurkan

## Translations

- Czech, German, Swedish, and Brazilian Portuguese by ⚡ Dee Kay ⚡ (nprofile…m3sx)
- Polish by Polak (nprofile…8c53)
- Hungarian by summoner (nprofile…ns2l)
- Hindi by राज (nprofile…z0lu)
- Russian by Anton Zhao
- Slovenian by StellarStoic (nprofile…3gag)

Nostr event nevent1qqsqqqzawqhrqe5jln6wrlrrxgv6305u39ltu8h3yvm88y2rh7u6ypgzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zur7en7

2026-10-05T09:13:47Z

A stick with a nail to rule them all

2026-10-04T14:04:34Z

In reply to nevent1q…m5w0
_________________________

A stick with a nail to rule them all

Quite depressing ngl

2026-10-04T12:35:22Z

In reply to nevent1q…0w2d
_________________________

Quite depressing ngl

Peak ux xD

2026-10-03T13:35:44Z

In reply to nevent1q…dvej
_________________________

Peak ux xD

I think we've reached that time of the year when I rewatch ...

2026-10-03T11:45:31Z

I think we've reached that time of the year when I rewatch the entire lotr movies

Are u a dementor?

2026-10-02T20:10:26Z

In reply to nevent1q…g7tl
_________________________

Are u a dementor?

@nprofile…at7q when you moving to Vienna?

2026-10-02T08:15:06Z

In reply to nevent1q…w6yw
_________________________

gsovereignty (nprofile…at7q) when you moving to Vienna?

Nostr event nevent1qqsqqq9zwcz66dj4r9kdcm4szk5uhzlee0kmgt5p3l8t9cxjmktkfsczypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z8rrg9w

2026-10-02T08:14:31Z

GM🖖

Thanks for the appreciation note 🫂

2026-10-02T08:01:16Z

In reply to nevent1q…aq9d
_________________________

Thanks for the appreciation note 🫂

@nprofile…gw67

2026-10-01T20:54:50Z

In reply to nevent1q…2dg4
_________________________

sandwich (nprofile…gw67)

https://music.youtube.com/watch?v=qvgHPC5l_cI

2026-10-01T19:32:29Z

https://music.youtube.com/watch?v=qvgHPC5l_cI

Nostr event nevent1qqspgsz8hcufpr08hpx8kq6p5e03n2dcpddgt8c803hrtfk9q4ta34szypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z999y23

2026-10-01T11:50:56Z

Mood

You stink bag of boogers

2026-10-01T08:58:36Z

In reply to nevent1q…53z8
_________________________

You stink bag of boogers

GM

2026-10-01T08:57:48Z

In reply to nevent1q…qpyk
_________________________

GM

Nostr event nevent1qqsqqqp2fh9tcvsh44fdm44ttjtusa5r4h9tqmle97x5zcnk9xw3r3gzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zjl5dpg

2026-10-01T08:33:52Z

GM🖖

Wasn't the first time wouldn't be the last one... The way ...

2026-10-01T08:33:36Z

In reply to nevent1q…ar7y
_________________________

Wasn't the first time wouldn't be the last one... The way the protocol its managed is pretty informal and childish

I mean, you could stop saying it right now, since it is not. ...

2026-09-30T21:49:28Z

In reply to nevent1q…zs4w
_________________________

I mean, you could stop saying it right now, since it is not. There is no single coordinator run by a company or nothing like that, and it's also a protocol ya know, sandwich made a client, now cloud is making his own, all of them interoperable, no obligatory coordinator anywhere. But yea, hardening and federation are important points and they are already in the works.

And yea, concord so far inverts the nip-17 expectations, specifically this point https://github.com/nostr-protocol/nips/blob/master/17.md#relays . If you guys change that part of the spec I will shut up, but so far I think you still using the pubkey of the channel as author. So relays need to choose, be compliant with nip-17 or concord. I buy that is not at hard measure and any plain relay will work, thats why I said 'work as expected' in my comment, not just that doesn't work in regular relays.

That’s simply not true. First of all, anyone is free to run a ...

2026-09-30T21:30:04Z

In reply to nevent1q…gjtq
_________________________

That’s simply not true. First of all, anyone is free to run a coordinator, even on a phone or in a browser tab! no ip, no networking required... much easier than running a public relay if you ask me... Also, no events are stored on any relays, so users are truly sovereign, and this also comes with great privacy advantages. No external observer can know anything, and there’s no collect now decrypt later. The fact that the only things that touch relays are ephemeral events also reduces attack vectors by a lot.

But in any case, you guys, all of you who claim that cordn is centralized and use that to diminish it, have a point: one coordinator at a time is the only way to ensure things work. But you are about to lose even that point. We are already working on multi coordinator arrangements, so there won’t be any single points of failure. Everyone in a community can run their own coordinator (on their phone if they want) and all of them will ensure that comms can continue even if some are down.

On the other hand, your argument doesn’t have much value when Concord itself needs special relays to work as expected and mitigate spam, which, from my pov, is a centralization vector.

Which indeed reads like slop. #nevent1q…rnup

2026-09-30T13:50:37Z

Which indeed reads like slop.

quoting
nevent1q…rnup
SIops

Nostr event nevent1qqsqqqpzxhf963ezk4camcd6mh7jvr8ckaft37zckavvzrwnvce2yaszypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zct2z5n

2026-09-30T13:50:02Z

SIops

GM 🖖 ...

2026-09-30T08:49:55Z

GM 🖖

I respect your opinion, and it's true, this is not Bitcoin. ...

2026-09-29T16:49:29Z

In reply to nevent1q…4qka
_________________________

I respect your opinion, and it's true, this is not Bitcoin. That wasn't my argument anyway. But I think it does matter, especially for dev expectations and consistency across the network, which is already quite confusing. It is true that there is no specific limit set anywhere in the protocol, and that 64 KB is just an informal convention, but so far, the bigger the events are, the more people with poor connectivity suffer. Also, it is the wrong technology for storing blobs. But anyway, good luck with your campaign. I think you can work around this without needing all relay implementations to converge on increasing the event size limit.

One thing doesn't imply the other, but who cares anyways...

2026-09-29T16:17:25Z

In reply to nevent1q…hml9
_________________________

One thing doesn't imply the other, but who cares anyways...

To be honest, I don't think this is the way. Not just because ...

2026-09-29T15:42:59Z

To be honest, I don't think this is the way. Not just because it is an arbitrary value. Why 1 MB, and why not 4 MB... or more? But also because it doesn't make sense to force application logic or demands into what should be a protocol level change, if any... Pagination, chunking, all of that already works out of the box. Increasing event size limits is unnecessary churn and would never end up being satisfactory for everyone. So this would probably either make things even more inconsistent for devs who expect relays to store 1 MB+ events or, more likely, make wn need to run special relays.

quoting
nevent1q…urzr
Hey relay runners!

It's time to raise the event size limit on your relays. 64kb is so 2023. 1MB+ is the hot stuff now.

We're trying to support groups larger than ~60 on White Noise (nprofile…9puf) and the limiting factor is inbox relays rejecting events that are larger than 64kb. White Noise handles it beautifully when your inbox relays don't block it.

Yea and all evil

2026-09-29T11:53:21Z

In reply to nevent1q…e9en
_________________________

Yea and all evil

Hehe good luck

2026-09-29T10:44:47Z

In reply to nevent1q…xhy2
_________________________

Hehe good luck

Nostr event nevent1qqsqqq84a73p48j4wwsdz2zjgthqs8mmtrtsw5pd566kfz0rxpw0s8czypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z032tus

2026-09-29T08:22:59Z

GM🌞

CS degree. And with CS I mean counter strike

2026-09-28T19:34:21Z

In reply to nevent1q…dwwk
_________________________

CS degree. And with CS I mean counter strike

This is an interesting way definitely 👀

2026-09-28T13:06:22Z

In reply to nevent1q…vewl
_________________________

This is an interesting way definitely 👀

Hahaha that's exactly it

2026-09-28T09:38:14Z

In reply to nevent1q…mmhz
_________________________

Hahaha that's exactly it

GM 🌞 ...

2026-09-28T09:31:45Z

GM 🌞

Maybe you find this interesting #naddr1qv…7qdm ...

2026-09-27T19:16:20Z

In reply to nevent1q…6gtw
_________________________

Maybe you find this interesting

quoting
naddr1qv…7qdm

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

https://njump.me/naddr1qvzqqqr4gupzqs9eep0ll6hurjkl3sc2fewgses07mjfwxsdcu3at2m8fd0xrdz3qy88wumn8ghj7mn0wvhxcmmv9uq3wamnwvaz7tmjd9kx7tnwdaehgunfvyhxzurs9uqrzurjd9mxzar9943k7mtdw4hxjcmpw35k7mnn94hhvetj94c82cnvd93j66twveexzum5wf6kxar4wfjsc27qdm

Nostr notes by Gzuuus

Gm

https://www.youtube.com/watch?v=uuKOXGVIP8I

Nostr event nevent1qqsy32eeu38dzln9v8jlynf9g8qvtp60ps0h0lqmr2fpgcfpelpf2sszypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zzefxs7

Nostr event nevent1qqsx7eldzcg8gpx8d57dxmyyy5fkeawqac6w3n26l7dzhwkvndwn5kqzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zm0jggk

Nostr event nevent1qqs2x3qdszd2j7wpf2ady88qh6de6jmrywq8tyc8q2t9s3m43amqx7qzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z2nuhfs

... My kind of humor ...

Ngu tech #nevent1q…pjna

But being honest just Pretty Hysteric People #nevent1q…66tl

Nostr event nevent1qqsr63u07e8k0kcptylrp8gvnvda898d2mhlcnre34hdspp6kdz7fxqzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z3wwuc5

Hahaha these vids are amazing

Nostr event nevent1qqstuzmxev02dvukhk947v8ms3xgh96nw97quy03jvhjfprchpfy7zszypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zgxwxmr

This is crazy... Wild times ahead ...

Nostr event nevent1qqs8fwhk0w7t3686h2547ad2kdm2llzg0svpm65300ajjv5ll20xkvczypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z4yhddv

Nostr event nevent1qqsgckauwfutzv2j720x906zvegnxge5lwh27zr6n39wzeqtgwgkepczypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zzd24yq

Tbh I was testing in my phone and didn't had to much time, it ...

LFG! Looking forward for this

LFG!

https://music.youtube.com/watch?v=RqckEWeHGgg

Did many successful tool calls, but got stuck at getrawmempool

Seems he got his arm damaged in the simulation

GM dany trejo

Nostr event nevent1qqstqkqmjynzlnyrqmzwt7020yrwheyn7gkm2yqpltufc0uxs95kjrszypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z6cgg2s

Nostr event nevent1qqsghz2vk7ljnr73xfdj3kxp5r8gwjrfdrgs07f9jz6eafscgxedy7qzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zfcedf8

GM Quiche eaters ...

It's fri https://music.youtube.com/watch?v=c3P3lKFqYYM

I wish... xD

Nostr event nevent1qqsva2ltr7v92kj87drreuvusannscp5f2ks7fzgghkpttc36hxjyfczypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69ze5asek

Defo not satisfying real hunger xD ...

Nostr event nevent1qqsdmnyvd582quzx99j68dl3stspyg8qdc2sp3nxp64yue9hvg9fgqszypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zxf4puc

Gradient descent

Hahaha this is funny, that's my terminal window btw, the ...

GM 🌞 lately I'm developing the habit of just as I wake up ...

Nostr event nevent1qqsyv5sc93qdktj8y8p022xtgf9gknhyutjm5jaf088kexxhqy8upkgzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zwd8uxj

Nostr event nevent1qqsfvr229jgws4kf5hu7zxldmct9w85tpeu2a69u53yuv2y2luwqtggzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z3w7ggt

I assume peas hahaha

Is there any possible answer? Hahaha

It's a peaceful life ...

Lmfao reddit is an special place... ...

Nostr event nevent1qqszvklwaz0kmrlx5n8t8tj36h7j5degxwc3d0wgrdan2ny87zwtx3czypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zumuql5

Kindof

Nostr event nevent1qqspq95pd5hujr3tjx4k5vwhraeyhv53dwjrkmcjeyzrljauryu0hngzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z3fy2uv

Nostr event nevent1qqsrj9nvkvz856kyeqc3yjlekeppz4g73zmmc0cqv5leya8ds8axlkgzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zc2uxvg

GM 🫶

Will print this note and hang it on my wall 🔥

Man this is hilariously painful xDD

Oh yea... Sure they will expose it... XD crazy times

Incredible the level of face washing just after few years this ...

I'm not surprised 😅

Maths ⚔️ slop ...

GM 🫶

https://www.youtube.com/shorts/AYQhWSSHrFY

Great day 🌞 ...

You're giant 🫶

Nostr event nevent1qqsqqqygq32vj6kmumjm6439fvn09ypc2ef67ldfjlerwc669w6es3gzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z32wq50

This feels like vegan meat

I think @nprofile…udid it already?

GIFs! 🔥 #nevent1q…wdkn

Man stop using my gms for quoting this crazy notes, I don't ...

GM #nevent1q…48dp

Very cool 👀

Red wine. I'm testing different flavors. Peach is pretty good

Hahaha they are happier now

No, it makes you stronger

Mixing wine and kombucha. I'm calling it kombolutxa, like ...

Why are you quoting me like this?

Nostr event nevent1qqsqqqphla98jtp8dxmvpe3pvkhhuqqphxcu635w57288j8337dlqcqzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zqgps84

Massive! Amethyst supporting Cordn 🔥 Little by little, the ...

Nostr event nevent1qqsqqqzawqhrqe5jln6wrlrrxgv6305u39ltu8h3yvm88y2rh7u6ypgzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zur7en7

A stick with a nail to rule them all

Quite depressing ngl

Peak ux xD

I think we've reached that time of the year when I rewatch ...

Sponsored by electrolytes ...

Are u a dementor?

@nprofile…at7q when you moving to Vienna?

Nostr event nevent1qqsqqq9zwcz66dj4r9kdcm4szk5uhzlee0kmgt5p3l8t9cxjmktkfsczypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69z8rrg9w

Thanks for the appreciation note 🫂

@nprofile…gw67

https://music.youtube.com/watch?v=qvgHPC5l_cI