Nostr is a distributed publish-subscribe protocol in which clients publish signed events (“notes”) and subscribe to others’ events using filters. Relays act as lightweight store-and-forward servers that index, persist, and broadcast events to connected subscribers. However, because Nostr connections are typically made directly over WebSocket, clients expose their IP addresses to relays, allowing for potential metadata correlation.
The proposed Oblivious Nostr Relay (ONR) design introduces a privacy-preserving gateway that forwards encrypted client requests to a target relay without revealing the client’s network identity. Functionally, the ONR acts as an application-layer proxy analogous to an Oblivious HTTP (OHTTP) relay, but implemented using Nostr primitives
Clients giftwraps their requests using the target relay’s npub and encapsulate the ciphertext within a Nostr event intended to the ONR. The "outer" event includes metadata identifying the intended destination relay, while the payload remains opaque to the ONR. Upon receipt, the ONR forwards the encapsulated giftwrap payload. The target relay decrypts the message, processes the request, and responds -- without being able to associate the request with the originating client.
The transport mechanism between the ONR and the destination relay remains an open design question. The ONR could maintain a persistent WebSocket connection for low-latency forwarding, or issue ephemeral HTTP requests for better isolation and statelessness.
To achieve request-level unlinkability, clients must generate a fresh ephemeral keypair for each encrypted request. This model works effectively for publishing events, since each post involves a single one-shot message that the ONR can forward without maintaining session state.
Subscriptions, however, introduce complexity. To stream subscriptions responses, the destination relay must encrypt and giftwrap each subscription message back to the client’s ephemeral keypair (or a long-lived npub?). Supporting this bidirectional encrypted stream requires the ONR to maintain persistent session state and open connections to both the client and the target relay. Consequently, ONRs cannot remain stateless if they are to support subscriptions -- which could be a fine tradeoff. Clients must also retain their ephemeral keypair for the duration of the subscription stream. Even for posting events, new ephemeral keypairs remain necessary to preserve unlinkability across sessions.