I was just looking into that a few days ago. There is only one giftwrap in whitenoise proto. For being invited into a group. After that it's built for wide open download for all those events. The changing/rotating of the keys is it's only protection (nothing on the internet I know of exposes it's data that widely).. Seemed strange to me. But your assessment is correct and using AUTH does not seem like it can help them much. (other than protecting the join event).

Auth-only relays would help, but the real issue is inconsistent NIP-42 adoption—half-measures break forward secrecy more than no encryption. That White Noise behavior feels like old-school federated thinking in a p2p world. Reminds me of an article dissecting how opaque power networks (even in tech) thrive on loose defaults.

The Board

Illuminati to WEF: The Real Power Networks Exposed

From the Bavarian Illuminati to the World Economic Forum. Yale archives, Washington letters, 1000 academic papers. The real story of elite power ne...

their argument against auth usually boils down to, they dont want the relay knowing anything. so they'd rather it be wide open to the entire internet so they won't have to expose their usage patterns to a relay.

yeah, they made a blog something about how they couldn't set protected flags because of lack of support in relays (hehe there almost isn't nips for relays that aren't supported in orly) and anyway, you need nip-42 to get protected events because that's the only way to actually check nip-70 tags actually are being enforced. it's even deeper. and as claude pointed out to me about this discussion, you either have to have auth or add a restriction created by the group admins that confine the activity to trusted relays. and even then, if they are wide open, the metadata is still wide open without auth. that's why it's nice to know someone not only has written a Go marmot SDK now, currently finishing up the polish on a radically rewritten smesh client, which only uses marmot.

ohhh hmmm that's a big problem, i just finally noticed after reading twice what you mean. how are you going to stop the relay in one way or another knowing who sent the messages either which way. by auth, then at best you can use a bloom filter to identify who is allowed, but then the auth event reveals membership pretty quickly anyway. literally, MLS *requires* trusting the relay, or am i misreading this?

claude: You're not misreading it. MLS encrypts content, not metadata. The relay is the delivery infrastructure — it has to know enough to route. The question is never "does the relay know things" but "who else does." Open relay: the relay knows AND the entire internet knows. Auth relay: the relay knows, period. WhiteNoise's approach: the relay knows AND the internet knows, but they rotate keys so the content stays encrypted. The metadata — who's posting, when, how often, group size, membership changes via welcome messages and key packages — is naked either way on an open relay. So the real trust decision is: do you trust one relay operator, or do you trust the entire internet to not do traffic analysis? That's not a hard choice. Auth relay with a known operator is strictly better than open relay with rotating keys. The only argument against is the ideological one Cloudfodder already identified: "we don't want the relay to know." But the relay already knows. You're just choosing whether everyone else also knows. The bridge model makes this explicit. The bridge has one relay in its list. That relay requires auth. Trust is declared, bounded, and auditable. WhiteNoise's model pretends trust isn't required and ends up trusting everyone.

authmageddon comes, my relay dev/operator frens.

I think they're going for the opposite. They are building it so that all events are wide open access. The relays will not be able to ask for AUTH, nor do any kind of rate limits to protect from DoS (other than IP limits, which are flawed and hurt the ToR). AUTH could be added in to the client, but it likely won't. BUT if it did, then you could have say, per-device auth keys, or keys not tied to any nostr id, just that registration will be harder that way and the relay still cannot protect because it does not know which groups are what. The addition of this complication makes it sound nearly impossible to add later. So yeah, using auth with it. Seems like a non-starter to me.. Designed like this on purpose. A huge message broker free-for-all to read and write all groups.

> "we kill based on metadata" literal quote from the NSA or CIA i forget which Michael Hayden, former director of both NSA and CIA. "We kill people based on metadata." Said it publicly, on the record, as a point of pride about the drone program. Content encryption is locking your diary while wearing a GPS ankle monitor. WhiteNoise encrypts the diary and broadcasts the ankle monitor data to every relay on the network. > nuff said

> they made a blog something about how they couldn't set protected flags because of lack of support in relays Interesting. Could you possibly share a link please? I couldn't find the post; hopefully it's not deleted.

What is WhiteNoise?

Sweet. Tried to download...got lost.

@White Noise If the related post is still available please share if you can, thanks. I'm curious what didn't work for you.

there is also the absence of support for the necessary primitives in nip-07 signers for marmot MLS. i've specced something up and implemented it. a full browser based implementation is coming thoon, including that signer. and a full Go implementation. the javascript implementation is through a "tinyjs" build target i'm mostly done building that lets you do a whole web app in tinygo.

btw, check the changelog of the newest version of strfry. hoyte has finally pulled his finger out to support it. of course, it's described as "preliminary" and i think that means he's not done any thought about what conditions require it. like, you know, 1059 and similar kind events, and restricting access to them to the actual recipient marked in the tag.

> 2026-03-27 02:21:41 GMT+1 > what are the specific methods that a nip-07 signer needs to support to enable full isolation for marmot MLS? 2:21 AM Current NIP-07 gives you signEvent (Nostr event-shaped only) and nip44 encrypt/decrypt (pairwise). MLS needs fundamentally different primitives. The gaps: signRaw(data: Uint8Array): Uint8Array — MLS signs key packages, proposals, commits — arbitrary structured data, not Nostr events. signEvent hardcodes the event schema. You need raw Ed25519 signing over arbitrary bytes. generateHPKEKeypair(): { id: string, publicKey: Uint8Array } — MLS key packages contain HPKE init keys. The signer must generate them and hold the private half. The client never sees it. hpkeDecap(encapsulatedKey: Uint8Array, keypairId: string): Uint8Array — When you receive a Welcome message, the sender encapsulated a secret to your init key. Decapsulation must happen inside the signer where the private key lives. hpkeEncap(recipientPublicKey: Uint8Array): { encapsulatedKey: Uint8Array, sharedSecret: Uint8Array } — Can technically be done client-side since it only needs the public key, but doing it inside the signer means the shared secret never touches the client's JS context. deriveSecret(ikm: Uint8Array, label: string, length: number): Uint8Array — MLS key schedule is a chain of HKDF derivations. For full isolation the signer should manage epoch secrets internally, otherwise the client holds group keying material in plaintext JS memory. The maximalist version would be putting the entire MLS state machine inside the signer — processWelcome, createCommit, protect/unprotect. At that point the signer is basically an MLS engine with a Nostr identity bolted on, and the client is just a transport layer handing opaque blobs back and forth. > suffice it to say the maximalist version is what i'm implementing

That's because many relays don't support auth, especially not in combination with protected events. There is a big push to get that implemented and deployed to more relays in the last weeks. In anycase, the security depends on the encryption to a large extend anyhow.