New encryption, the same Nostr relays

Three different jobs

The sender and recipient need to agree on encryption. The relay needs to decide what it can accept and what it can validate. Those decisions overlap at the event boundary, but they are not the same capability.

In the existing hybrid-DM composition, the message is encrypted inside a seal and carried by a standard outer gift wrap. A relay sees that outer event. It does not need the recipient's secret key or an implementation of the inner encryption method to transport it. It still checks the visible signature, size, access rules and the event handling required by the protocol.

Sender, relay and recipient responsibilities

This makes the relay content-agnostic within its policy. It does not make an old recipient able to decrypt a new format. Both endpoints need compatible support.

A small selector, a complete specification

The existing local envelope already starts with one version byte and one suite byte. A suite defines the whole construction: algorithms, key sizes, the key combiner, authenticated fields, padding and encoding. A number alone is not a cryptographic design.

A future suite needs review, exact byte definitions and test vectors before that number is assigned. Readers should be implemented before writers start choosing it by default. The readable capability information lives in discovery; the repeated message carries the compact selector. Ordinary events gain no universal encryption field.

Consider Alice and Bob. Alice has suites A and B; Bob supports only A. They can choose A if their policy permits it. If Alice requires B, sending stops. Once Bob upgrades and publishes a valid capability/key binding, they can use B through the same relay, provided the larger event fits its rules. A failed attempt must not silently resend the message with weaker encryption.

What relays could advertise

The proposal builds on NIP-11 relay information. Existing size limits remain useful; proposed fields describe admitted event kinds and public proof requirements. For example, an operator could accept encrypted gift wraps and separately require a hybrid signature on public posts.

That distinction matters for privacy. An ordinary gift wrap is signed by an ephemeral key. Requiring the hidden sender's stable proof on the outside would expose the identity the wrapping is intended to hide.

A relay acknowledgment confirms acceptance under its rules. The recipient still needs to authenticate the message, decrypt it and validate the application content. No acknowledgment proves that a person has read it.

The bytes are in the cryptography

In the reproducible audit fixture, a 280-byte chat message produces a 2567-byte classical gift wrap or a 5295-byte hybrid one. The proposed public signature adds 6275 bytes to an otherwise tagless event. Padding makes the final difference vary with message length; it is not a fixed multiplier.

The two selector bytes are a small part of that cost. KEM ciphertexts and signatures dominate. Group conversations also need separate recipient copies, and relay replication adds more traffic. A client should measure the complete wrapped event before sending, rather than compare the original text with a relay's limit.

What is ready, and what needs more work

The envelope and signer integration exist. The new relay policy vocabulary and public hybrid-authentication format are proposals, not newly released relay features. Authentication still needs complete key-rotation and event-reference rules, plus independent cryptographic and interoperability review. The classical outer wrap also means the existing design does not provide post-quantum protection for all metadata.

The practical direction is incremental: let capable peers protect content, keep relay requirements explicit, and introduce new suites without changing what old suite identifiers mean. The illustrated flow guide includes rollout examples and failure paths; the audit includes the size model and remaining work.