What a relay needs, and what it does not
A relay is any system that passes a message along without being its final destination. Mail servers relay email, TURN servers relay packets between hosts that cannot reach each other directly behind NATs, Nostr relays store and forward events over WebSockets, and in a mesh, ordinary phones relay messages for each other. What is a relay server? covers the role in general.
To do its job, a relay needs to know where a message is going. It does not need to know what the message says. RFC 5321, the email transport standard, puts this as a rule: a relay SMTP server “has no need to inspect or act upon the header section or body of the message data” and must not do so, apart from adding its own trace header.
Not reading is a policy, though. Cannot read is a property of the cryptography, and only the second survives a relay that is careless, compromised or hostile.
Encrypt before the message leaves
The relay cannot read a message when the sender encrypts it for the recipient’s key before sending, and the relay never holds the matching private key. That is end-to-end encryption: the ends hold the keys, and everything in between carries ciphertext.
The alternative, encrypting each hop separately, does not achieve this. With TLS from sender to relay and again from relay to recipient, the relay decrypts and re-encrypts, so it sees the plaintext in between. The TURN standard is explicit: confidentiality for relayed application data is best provided by the application protocol itself, because running TURN over TLS does not protect the data between the server and the peer. RFC 5321 says the same of mail, that real mail security lies only in end-to-end methods applied to message bodies, such as PGP or S/MIME.
Authenticated encryption stops tampering
Hiding content is half of the job. A relay that cannot read a message might still try to change it. Authenticated encryption with associated data (AEAD), specified as an interface in RFC 5116, handles both: it provides confidentiality and a way to check integrity and authenticity. If the ciphertext has been altered, decryption returns a failure instead of plaintext.
AEAD also fits the relay problem neatly through its associated data. RFC 5116 explains that some fields, such as addresses, ports and sequence numbers, must stay in the clear so the network can handle and forward the message, but should still be authenticated. Those fields go in the associated data: readable by the relay, protected against change.
In a group, AEAD only proves that the sender held the group key, so protocols such as MLS also sign messages with each member’s key. RFC 9750 states that even a malicious MLS delivery service cannot add itself to a group or recover the group key.
Sealing the envelope too
Encrypted content still travels with a visible envelope. Nostr’s NIP-59 defines a gift wrap that hides most of it:
- A rumor is the unsigned event holding the content.
- A seal encrypts the rumor and is signed by the real author, with no tag naming the recipient.
- A gift wrap encrypts the seal and is signed by a random, one-time key. Its visible tags carry what routing needs, such as a tag for the recipient.
The encryption at each layer follows NIP-44. A relay sees a one-time author key, a recipient tag, a timestamp the specification says should be tweaked, and ciphertext.
Offline Protocol’s SDK documents both layers. In its mesh, phones that relay a message forward MLS ciphertext. Its Nostr envelopes are sealed by default as NIP-59 gift wraps with NIP-44 encryption, around application messages that are already encrypted with MLS, and its docs note that a Nostr relay still sees subscriptions, timing and volume.
What a relay still learns and can do
A relay that cannot read or alter content is still not powerless.
- It sees metadata. NIP-44 lists its own limits, including that relays may see a user’s IP address and that padding only partially hides message length. What is metadata, and does encryption hide it? goes further.
- It can withhold. RFC 9750 notes that a delivery service can refuse to relay messages to and from a client, and that other clients generally cannot detect this without side information.
- It can delay or resend. A relay can hold messages back or send copies again. RFC 9750 says MLS aims to stop even a compromised delivery service from undetectably removing, reordering or replaying messages, but apps still meet duplicates and late arrivals, which is why receivers use deduplication and acknowledgments.
End-to-end encryption turns the relay from a party you must trust with content into one you only rely on to deliver. Which relays to rely on, and what they may observe, remains a decision for each deployment.