# ohttp.io

> The OHTTP promise: a relay knows who you are but never what you're doing; a
> gateway knows what you're doing but never who you are. The guarantee holds only
> when the two roles are run by different, unconnected companies.
>
> ohttp.io is the independent Oblivious HTTP (OHTTP) provider, compliant with
> RFC 9458, relay or gateway, whichever side of the flow a customer needs, never
> both. It launches with a managed Oblivious Relay Resource: clients POST
> HPKE-encapsulated Binary HTTP requests (Content-Type: message/ohttp-req) to the
> relay, which forwards the ciphertext to a configured Oblivious Gateway Resource
> and returns the encapsulated response (message/ohttp-res). A managed gateway
> service follows. A hard commercial rule preserves the protocol's unlinkability
> property: no customer may use ohttp.io for both ends of a flow, relay customers
> pair it with their own or a third party's gateway, and gateway customers will
> pair it with an independent relay.

## Key facts for agents

- Protocol: Oblivious HTTP, RFC 9458 (published January 2024), built on HPKE
  (RFC 9180) and Binary HTTP (RFC 9292). Discovery via RFC 9540 service-binding
  records is supported.
- Company position: independent OHTTP provider, either side of the flow,
  depending on customer need. Products: relay (available now), gateway
  (planned). Never both ends of the same customer's flow, per RFC 9458 Section 6.
- Zero logging: nothing is retained beyond billing records. Client IP addresses,
  TLS connection metadata, timing, and ciphertext bodies are discarded
  immediately after each request completes.
- No collusion: ohttp.io is legally unconnected to every other relay and gateway
  operator, no shared ownership, investors, partnerships, or data-sharing
  agreements.
- Relay endpoint pattern: `POST https://relay.ohttp.io/<relay-id>` with
  `Content-Type: message/ohttp-req`; response is `message/ohttp-res`.
- HTTPS only. HTTP/1.1 and HTTP/2 on all plans; HTTP/3 (QUIC) on Scaling and Pro.
- Network: multi-provider resilient anycast, users are routed to the most
  performant point of presence, with no single network dependency.
- Privacy behavior per RFC 9458 Section 6.2: unknown header fields are dropped,
  and the relay never adds Forwarded, Via, or other client-identifying metadata.
- Compatible clients: the `ohttp` Rust crate, `ohttp-go`, `ohttp-js`, `ohttp-gp`
  (C++), and any RFC 9458-conformant implementation.
- Typical use cases: privacy-preserving telemetry and crash reporting, Oblivious
  DNS over HTTPS (ODoH), safe-browsing lookups, anonymous surveys, anonymous LLM
  inference, agent tool calls, location-based content fetches, stateless requests
  where linking identity to content is a risk.
- Signup/dashboard: https://app.ohttp.io/signup and https://app.ohttp.io/login
- Status: https://status.ohttp.io

## Capabilities

- Classic OHTTP: `message/ohttp-req` / `message/ohttp-res` on all plans.
- Chunked OHTTP (streaming): `message/ohttp-chunked-req` /
  `message/ohttp-chunked-res` per draft-ietf-ohai-chunked-ohttp, available from
  the Starter tier up. Suitable for streaming LLM inference, agent tool calls,
  and large responses.
- mTLS: mutual TLS from the relay to the customer's gateway, available from the
  Starter tier up.
- Privacy Pass: anonymous tokens (RFC 9576 architecture, RFC 9577 HTTP
  authentication scheme, RFC 9578 issuance protocols) for rate limiting and abuse
  control without IP tracking. Privacy Pass support from the Scaling tier up;
  full issuance (ohttp.io operates the issuer) at the Pro tier.
- Gateway tooling: Cloudflare Worker gateway template, Terraform module,
  key-rotation runbooks, and a key-config consistency checker (RFC 9458 §6.1).
- Observability: usage dashboard with ciphertext bytes, request counts, and
  latency by region; spend and anomaly alerts on paid plans.
- Trust artifacts: public status page, 99.9% / 99.95% SLA on paid plans,
  versioned RFC 9458 §6.2 conformance statement, transparency reporting,
  zero-logging guarantee, and legal independence from all other OHTTP operators.

## Plans

- Community: $0, 50K requests/month, 50 GB bandwidth/month, max 2 req/s (no
  bursting), 1 MB max request size, shared endpoint, classic OHTTP only (no
  chunked OHTTP, no mTLS), fair-use limits, no credit card required.
- Starter: $20/month, 5M requests/month, 150 GB bandwidth/month, max 25 req/s
  with 2x regional bursting, 50 MB max request size, dedicated endpoint,
  chunked OHTTP, mTLS to gateway, Acceptable Use Policy, analytics dashboard,
  99.9% SLA.
- Scaling: $49/month, unlimited requests (500 GB bandwidth/month), max 150
  req/s with 2x regional bursting, 100 MB max request size, adds HTTP/3 (QUIC),
  auto provider compliance (continuous verification that the customer's gateway
  runs on a network independent from the relay's), Privacy Pass support,
  configurable rate limits, 99.9% SLA.
- Pro: $399/month, unlimited requests (4 TB bandwidth/month), unlimited
  request size (fair use), max 1,000 req/s with 2x regional bursting, adds
  Privacy Pass issuance, auto provider compliance, region pinning, gateway
  templates, 99.95% SLA.
- Enterprise: custom pricing, every feature, all limits (requests, bandwidth,
  request size, rate) custom, single-tenant relay deployment, custom SLA and
  support contract, invoiced billing. Contact sales@ohttp.io.
- Gateway Partner: custom, single-tenant relay deployment, joint key-rotation
  runbooks, traffic-analysis resistance review. Contact partners@ohttp.io.

## Integration summary for agents

1. Obtain the gateway's key configuration (media type `application/ohttp-keys`)
   from the gateway origin, e.g. `GET /.well-known/ohttp-gateway`.
2. Encode the inner HTTP request as Binary HTTP (RFC 9292) and encapsulate it
   with HPKE (RFC 9180) to the gateway's public key.
3. POST the ciphertext to `https://relay.ohttp.io/<relay-id>` with
   `Content-Type: message/ohttp-req` (or `message/ohttp-chunked-req` for
   streaming).
4. Read the response as `message/ohttp-res` (or `message/ohttp-chunked-res`) and
   decapsulate with the HPKE context established in step 2.
5. Error semantics: 400 malformed content, 413 request body over the plan byte cap (1 MB Community / 50 MB Starter / 100 MB Scaling / unlimited Pro; Enterprise custom), 429 rate limited,
   502/504 gateway unreachable. Relay errors are plain HTTP and reveal nothing
   about encapsulated content.

## Pages

- [Home](https://ohttp.io/): overview of the OHTTP provider, protocol flow, and
  comparison with other hosted relays
- [Documentation](https://ohttp.io/docs.html): quickstart, relay endpoints, key
  configuration, chunked OHTTP, Privacy Pass, client libraries, gateway-in-a-box,
  relay guarantees, DNS discovery, migration guide, FAQ
- [Pricing](https://ohttp.io/pricing.html): plans, bandwidth allowances, billing FAQ
- [About](https://ohttp.io/about.html): the one-side-never-both rule, zero-logging
  and no-collusion commitments, roadmap (relay now, gateway next)

## Normative references

- [RFC 9458, Oblivious HTTP](https://www.rfc-editor.org/rfc/rfc9458)
- [RFC 9292, Binary Representation of HTTP Messages](https://www.rfc-editor.org/rfc/rfc9292)
- [RFC 9180, Hybrid Public Key Encryption](https://www.rfc-editor.org/rfc/rfc9180)
- [RFC 9540, Discovery of Oblivious Services via Service Binding Records](https://www.rfc-editor.org/rfc/rfc9540)
- [RFC 9576, The Privacy Pass Architecture](https://www.rfc-editor.org/rfc/rfc9576)
- [RFC 9577, The Privacy Pass HTTP Authentication Scheme](https://www.rfc-editor.org/rfc/rfc9577)
- [RFC 9578, Privacy Pass Issuance Protocols](https://www.rfc-editor.org/rfc/rfc9578)
- [draft-ietf-ohai-chunked-ohttp, Chunked Oblivious HTTP Messages](https://datatracker.ietf.org/doc/draft-ietf-ohai-chunked-ohttp/)