Every encrypted message on Nostr today can be decrypted later by anyone who recorded it. Post-quantum keys derived from the seed phrase you already have close that gap - without changing your identity.
One checks somebody else. The other lets you watch the whole thing happen.
Look up any npub and see whether it has published post-quantum keys, whether the key lengths are right, and whether possession is proven.
Two identities register on public relays and exchange real ML-KEM encrypted messages. Take any event apart layer by layer and see exactly what a relay stores.
Three ideas, none of which require a relay to change.
Your post-quantum keys come from the same BIP-39 seed as your Nostr key, expanded separately. Neither key is derived from the other. That matters: if a post-quantum key were derived from your private key, an attacker who broke your Nostr key would simply repeat the derivation and get it too. Because the seed derivation is one-way, breaking your Nostr key reveals nothing about it.
The public keys live in a dedicated replaceable event rather than in your profile metadata. Clients rebuild profile metadata from the fields they recognise, so an unknown key would silently disappear the first time you edited your display name somewhere else - and you would never know.
The post-quantum payload travels inside the existing NIP-44 and NIP-59 layers, combined with the classic key rather than replacing it. Relays need no changes, and clients that have not implemented any of this are unaffected.
This protects the confidentiality of messages sent from now on, permanently, even against someone who records them today and breaks the cryptography later. It does not stop a quantum attacker from forging events in your name, because events are still signed with secp256k1. Fixing that means migrating signatures, which is a separate and much larger change.
What it looks up, and what to do with the answer.
It looks up the identity’s kind:10203 attestation on public relays and validates it: are the key lengths right for ML-KEM-1024 and ML-DSA-87, does the origin match the declared seed strength, and does the proof of possession verify.
Because that identity has not published one. There is no fallback and no guessing: without a published ML-KEM key there is no way to send them a post-quantum message, and reporting anything softer would invite a silent downgrade to classic encryption.
A secp256k1 signature proves someone published those bytes, not that they hold the matching post-quantum secrets. So the ML-DSA key counter-signs a message binding the npub and both public keys together. ML-KEM cannot sign, which is why this is also what gives the encryption key a possession proof.
Derive them from the 24-word seed phrase you already have — no new backup, and the same words still restore everything. The Nostr WoT extension can publish the attestation for you, or the guide walks through doing it offline from the command line.
It is a proposal, developed jointly by Nostr WoT and QuantaKrypto, built on the finalised NIST standards FIPS 203 and FIPS 204. It is implemented and running rather than theoretical, which is the point of the live chat demo.