ohttp.io has opened the limited-availability private beta of its independent OHTTP Relay. The relay stack is operational, and we're looking for developers, founders and organisations with real-world Oblivious HTTP use cases to help test and shape the service.
We're opening the ohttp.io OHTTP Relay
Today we're proud to open the ohttp.io OHTTP Relay to private-beta applications.
The relay stack is operational and ready for customer beta deployments. For this first stage, we're deliberately doing things personally. We'll talk to applicants about what they're trying to achieve, provision an OHTTP Relay appropriate to their geography and work directly with them through integration and testing.
We're starting this way because we don't want to build the service in isolation and guess what customers need. We want the people actually deploying Oblivious HTTP to help shape what ohttp.io becomes.
Why now?
Oblivious HTTP is moving from a protocol specification towards deployable Internet infrastructure.
Cloudflare has announced an OHTTP Gateway, including a deployment model in which customers use its Gateway with a third-party OHTTP relay. Fastly has previously described OHTTP Relay infrastructure, providing another real-world implementation of the relay side of the architecture.
Cloudflare and Fastly are independent companies and services. Neither company is being presented as an ohttp.io customer or partner. Their work does, however, demonstrate that organisations are developing real infrastructure around the separation of OHTTP relay and gateway roles.
We think independently operated relay infrastructure has an important place in that developing ecosystem. That's the part we're building.
What is Oblivious HTTP?
A conventional HTTP connection can expose information about the client making a request, including network-level information such as its IP address.
Oblivious HTTP (OHTTP) introduces a relay and gateway between the client and the destination handling the encapsulated HTTP request. The client encrypts its request for the gateway before sending it through the relay.
The relay receives the connection from the client and forwards the encrypted request, but cannot decrypt the encapsulated HTTP message. The gateway can decrypt the encapsulated request, but receives it from the relay rather than through a direct connection from the original client.
OHTTP doesn't make identifying information deliberately included inside a request disappear. Instead, it provides an architecture for separating information available from the client connection from the contents of the encapsulated HTTP exchange.
Where does ohttp.io fit?
ohttp.io is building independent Oblivious HTTP relay infrastructure. The ohttp.io OHTTP Relay sits between an OHTTP client and gateway, forwarding encrypted requests while helping separate client network identity from the plaintext request handled beyond the relay.
Our aim is to make that part simple to deploy, integrate and operate. Or, put rather more simply: Split the request from the requester.
Who are we looking for?
We're looking for organisations and developers with genuine OHTTP use cases: privacy-preserving APIs and applications; telemetry and analytics; AI and inference services; security and threat-intelligence services; mobile infrastructure; privacy-preserving measurement; IoT and connected devices; organisations operating or evaluating an OHTTP Gateway; and products where privacy can be designed in from the beginning.
If you're looking at a system and asking, “Do we actually need to know who made this request?” — we'd like to talk.
What beta users can expect
This isn't intended to be a faceless beta programme. We'll speak with applicants about their use case and requirements before going live. For accepted beta users, we'll provision an ohttp.io OHTTP Relay appropriate to their geography and work directly with them on integration and testing.
Beta participants will receive additional service credit in recognition of the time and feedback they contribute. Commercial pricing will be announced separately ahead of General Availability.
“Privacy shouldn't have to be bolted on afterwards. If you don't need to know who made a request, why collect that information in the first place? OHTTP gives us the technology to do something about that. Our job with ohttp.io is to make it practical, accessible and genuinely useful. Split the request from the requester.”
Something missing?
We're building ohttp.io around real problems, not a checklist of features we think people might want. If there's something you need from an OHTTP relay that you don't see here, tell us. A feature, an integration, a deployment requirement — or something we haven't thought of yet.
Apply to join the ohttp.io OHTTP Relay private beta →