my post-quantum proposals for Nostr

keys, discovery and messages — August 17, 2026

the first four drafts documented work that had begun with the key implementation on August 8

01 — key derivation. the post-quantum keys are derived from the BIP-39 seed as siblings of the classical Nostr key. deriving them from nsec would recreate the problem: an attacker who recovers that private key could run the same derivation. the profile uses domain-separated derivation for ML-KEM-1024 and ML-DSA-87, and requires a randomly generated 24-word mnemonic for this recovery path. independently generated keys need their own backup. the derivation draft specifies the recovery inputs and limitations

02 — key attestation. a sender needs to discover a recipient's encapsulation key before encrypting. the proposed kind:10203 event publishes the keys and an ML-DSA signature binding them to a statement about the Nostr identity. that signature proves possession of the ML-DSA secret, not possession of the ML-KEM secret. the outer identity binding is still classical, so the attestation draft cannot by itself prevent key substitution after classical signatures become forgeable

03 — hybrid message encryption. the envelope draft combines an ML-KEM secret with the NIP-44 conversation key. the encrypted rumor sits inside a seal, and the outer gift wrap still uses NIP-44. ordinary relays can transport the event within their limits, but recipients need the experimental decoder and the right keys. the aim is to protect recorded message content under the construction's assumptions; the outer metadata, event signatures and forward-secrecy problem remain separate

04 — signer capabilities. a page needs to know whether its signer can perform that encryption. an older JavaScript signer might simply ignore a new options argument and return classical ciphertext. the capability draft adds window.nostr.nip44.schemes, explicit selection and rejection when the requested method is unavailable. discovering support does not guarantee that every account in that signer has the necessary keys

these four documents describe experimental implementation work in the extension and SDK. integration through the same SDK is useful evidence, but it is not independent interoperability

relays and public authentication — September 11, 2026

the next two drafts address what happens beyond the encrypted message

05 — relay crypto-agility. the relay proposal keeps private payload transport separate from public signature verification. a relay does not need to understand an encryption method to carry its ciphertext. it does need to enforce message sizes, access rules and any public-proof policy it advertises. the proposed NIP-11 extension describes those capabilities without giving discovery the power to weaken client policy

06 — hybrid event authentication. the public-event proposal retains the ordinary event signature and adds an ML-DSA proof. upgraded verifiers would require both, together with a trusted key binding. the difficult work includes persistent trust, rotation, recovery, stripped proofs, and references to events after classical forgery becomes possible. this remains an unimplemented design requiring cryptographic review

evolving suites — September 12, 2026

07 — suite evolution and relay flows. the seventh document, added on September 12, works through upgrades where peers support different methods. it describes shipping readers before writers, selecting a mutually supported method under local policy, and preserving the keys and decoders needed for history. it is a proposal guide, not another implemented API

NIP-44 already has versioning. i am not proposing that Nostr needs to discover that idea. the open question is how to express and review a hybrid construction using the existing protocol, with clear key discovery, signer support and downgrade rules. the current envelope uses local experimental identifiers; they are not official NIP-44 allocations

the costs and the open work

the September size audit models a 280-byte chat message at 2,567 bytes for the classical gift wrap and 5,295 bytes for the hybrid one, about 106% more. the proposed public authentication proof adds 6,275 serialized bytes to an otherwise tagless event. those are reproducible fixture sizes, not network performance measurements; recipient copies, relay replication and other framing add further costs

there is also a public proposal history. i opened nostr-tools PR #541 on August 10; it was closed without merging. ConorClancy89 opened the related NIPs PR #2434 on August 11, linking the extension implementation. that PR remains open as of October 12. the later seven-document collection is maintained separately and none of its documents is an accepted NIP

my goal is a migration people can inspect and challenge in pieces. message confidentiality is the first useful step. independently reviewed constructions, interoperable clients and durable identity recovery are still necessary before claiming something broader