Connection privacy

Direct connections let consumers and providers exchange traffic without a gateway in between. As part of establishing that connection, each participant learns the other's network address. Encryption protects what they send, while their addresses remain visible to each other.

An optional relay could give participants a choice about that visibility. Their clients would communicate through a Direct-operated relay, keeping their network addresses private from each other while requests and responses remain encrypted end to end.

Trusting Direct-operated relays

Using a relay means trusting its operator with some information about the connection, including network addresses, timing, and traffic volume. With Direct-operated relays, that information is entrusted to Direct while each participant's address stays private from the other side. This is similar to the trust placed in a conventional aggregator gateway, though requests and responses remain encrypted between the clients rather than being readable by the relay.

The signed network definition includes relay identities and connection information, authorizing these peers to forward traffic between clients. The client verifies their authorization through the same trust anchor it uses to recognize Direct-operated peers responsible for the provider directory and verification.

Connections to Direct-operated peers remain direct, since using a relay would still expose the client's address to Direct.

Enabling connection privacy

The privacy option is enabled when starting the Direct client. Its effect depends on whether the client is consuming or providing services:

• For providers, it adds a privacy flag to offering announcements. Consumers use that flag to establish connections through a relay when selecting the offering.
• For consumers, it routes every provider connection through a relay, whether or not the provider requires one.

Applications continue using the same local API. The client handles the choice of connection path in the background.

Establishing the connection

When either peer requires privacy, the consumer's client connects to an authorized relay and asks it to establish a path to the selected provider. The relay carries traffic between the clients while keeping their network addresses private from each other.

Once the relay is forwarding traffic between them, the clients establish an encrypted session with each other through an end-to-end Noise handshake. The encryption keys are known only to the two clients.

Each client encrypts its service messages before sending them to the relay. The relay forwards those bytes unchanged, and the client at the other end decrypts them. This lets the relay route traffic and measure its size without having access to the requests or responses it carries.

Direct operates relays across multiple regions and data centers, with clients discovering them through the P2P network. If a relay becomes unavailable, the client can establish a new connection through another authorized relay. Recovery preserves the privacy requirement rather than falling back to a direct connection.

Paying for relayed traffic

Consumers always pay for relay usage, regardless of who requested privacy. Charges are based on the number of bytes transmitted and authorized through signed vouchers, using the same payment flow as other work on Direct.

The client knows which providers require a relay and accounts for that connection path when scoring candidates. It includes relay fees in the cost of using a provider and measures latency over the relayed connection, weighing both according to the consumer's preference for price or response time.

For a consumer who has not enabled privacy, choosing a provider that requires privacy will add relay fees to the request cost and another network hop to its delivery. Since the client scores providers based on price and response time, those additions tend to favor an otherwise comparable provider reachable directly. When the consumer enables privacy, every provider connection uses a relay, so each candidate is assessed with its relay fees and latency included.

Since consumers decide where to send their requests, charging them for relay usage lets them weigh that expense when choosing a provider.

Open questions

Two implementation questions remain open:

• Joining without exposing addresses: How will consumers and providers participate in the P2P network without discovery or connection setup revealing the network addresses associated with their public keys?
• Rotating identities: Should clients rotate their keys to make it harder to build a history of their usage? How would verification and payments work as identities change?