Why devices need a relay
Two devices often cannot open a connection to each other. Many phones and laptops sit behind network address translation (NAT), which lets them make outgoing connections but blocks unexpected incoming ones. Techniques called hole punching can sometimes get through, but RFC 8656 notes that they fail when both hosts are behind NATs that are not well behaved.
Timing is the other problem. A recipient may be offline, asleep or out of coverage when the sender is ready. A direct link needs both ends present at once.
A relay solves both. Each device makes an outgoing connection to a server that everyone can reach, and the server passes traffic between them. It is a middle hop, not the destination. That makes it different from a peer-to-peer network, where devices talk directly, and similar in spirit to a phone that forwards messages for its neighbours in a mesh.
Relays that forward in real time
TURN (Traversal Using Relays around NAT, RFC 8656) was designed for multimedia sessions such as SIP and WebRTC calls. A client asks a TURN server for a relayed transport address, gives that address to its peer, and the server then passes packets between them as they arrive. It stores nothing.
TURN is meant as a last resort. The RFC points out that relaying is costly for whoever runs the server, because it needs a high-bandwidth connection, so ICE, the connection-setup procedure used alongside it, tries for a direct path first and uses the relay only when none can be found.
A TURN server is not trusted with content. RFC 8656 says confidentiality for relayed data is best provided by the application itself, and gives SRTP for real-time media as the example. WebRTC makes this mandatory: RFC 8827 requires every media channel to be secured with SRTP, keyed between the endpoints. The relay moves encrypted packets it has no key for.
Relays that store and forward
Email has used relays for decades. RFC 5321 defines an SMTP relay as a system that receives mail and passes it on to another server without changing the message, apart from adding trace information. When a server reports success at the end of a message, responsibility formally passes to it: it must either deliver the message or report the failure. Mail that cannot go out immediately is queued and retried, which makes SMTP a classic case of store-and-forward messaging. Unless the mail itself is encrypted, each relay can read it.
Nostr relays work differently. NIP-01 describes relays as WebSocket endpoints. Clients publish signed events to them and subscribe with filters, and a relay answers each published event with an OK message saying whether it accepted it, with a reason when it did not. Relays are expected to store regular events and send them to later subscribers, so a recipient can collect messages after coming online. Events are signed by their authors, so a relay cannot alter one without the signature failing to check.
What a relay can and cannot see
End-to-end encryption changes what a relay is trusted with, but not everything. Messaging Layer Security (MLS, RFC 9420) assumes a “largely untrusted” Delivery Service that routes messages between members, and it is designed to protect the confidentiality and integrity of group data even if that service is compromised. The RFC is plain about the remaining power: a compromised Delivery Service cannot forge messages, but it can delay or remove them selectively, and it can permanently block messages to and from a member.
A relay also sees metadata: which devices connect, when, how often and how much they send. Encryption hides the content, not the pattern of traffic.
Relays in offline messaging
Offline-first apps use relays as one path among several. When two devices are close, they talk over Bluetooth or a local network. When they are far apart and each can reach the internet, even at different times, a relay carries the message between them, and an outbox holds it while neither path is available.
Offline Protocol’s mesh SDK is one example. Its hosted relay runs at wss://relay.offlineprotocol.com, is turned on per application in the developer portal, and accepts a device only with its signed-in user’s OfflineID session. Application messages are encrypted with MLS on the device, so the relay forwards ciphertext. Hosted relay deliveries are metered, while local peer-to-peer traffic is never metered.
Questions to ask about a relay
- Does it store, or only forward? If it stores, for how long, and what happens when that time runs out?
- Who can use it? A relay that accepts traffic from anyone can be misused. RFC 5321 lets mail servers refuse to relay mail for other destinations, and TURN requires every server and client to implement a credential mechanism so that requests can be authenticated.
- What can it see? Check what is encrypted end to end and what metadata remains.
- What happens when it is down? A good design falls back to local links or queues messages rather than losing them.