3 September 2026. Response to: "what else can the server do to hide who connects to send vs receive — i.e. other relays or vpn nodes for incoming perhaps or something similar making camping on netlify traffic to track just this app a bit more complex."
Checked in the code rather than recalled:
[256, 1024, 4096, 16384, 32768], mandatory rather than a setting, with a strict all-zero check on decode so padding cannot become a covert channel (mesh-core-rs/src/payload.rs, PROTOCOL.md §5.1/5.3). Message length is already coarse.[512, 2048, 8192, …], top bucket covering the worst case (server/netlify/functions/_shared.mts, DECISIONS.md J12).1. The hostname, in the clear, on every single connection. This is the biggest one by a wide margin. TLS still sends the server name unencrypted, so a passive observer reads channelmessenger.netlify.app and knows this device runs Channel — before any of the padding above matters. Everything else on this page is a refinement of a signal that this one gives away for free. No HTTPS/SVCB record with an ECH configuration is published for the host today.
2. Send is distinguishable from receive, which is the specific question asked. Not from the URL — that is inside TLS — but from direction asymmetry:
| Upstream | Downstream | |
|---|---|---|
| Deposit (send) | envelope, ≥256 B bucketed, plus headers | small, 512 |
| Collect, no mail | headers only | 512 |
| Collect, mail waiting | headers only | 2048+ |
So an observer separates senders from receivers by upstream size, and mail from no-mail by downstream bucket. Neither requires decrypting anything.
3. Bucket boundaries still leak magnitude, per J57 — not how many messages, but roughly how much.
### 1. Encrypted Client Hello — removes the "which app" signal entirely ECH encrypts the server name in the TLS handshake, so the observer sees a connection to a large shared CDN and nothing else. This is the highest-value change available because it defeats the signal that makes all the others findable in the first place.
It is not ours to switch on unilaterally: it needs the CDN to support ECH and the client to fetch the config over DoH. Verify Netlify's support before planning on it — and note the convergence with ATTACHMENTS-AND-COST.md, which already argues for moving storage to Cloudflare. If the platform moves, ECH becomes available with it.
### 2. Oblivious HTTP — this is the thing being described, and it is standardised RFC 9458. Requests go to a Relay, which sees the client's IP but not the request, and forwards to a Gateway, which sees the request but not the IP. Neither party alone can link an IP to a request, and only collusion between two separate organisations reconstructs it. Apple uses it for Private Relay and Safe Browsing; Cloudflare and Fastly operate managed relays.
The property this buys is worth stating exactly, because it is stronger than what we claim today: we currently say we choose not to log IP addresses. With OHTTP we would say we cannot see them — a claim that survives a subpoena, a change of hosting provider, and a change of heart.
Our traffic is a good fit: small, stateless, frequent requests. Polling through OHTTP is unremarkable.
The load-bearing constraint: the relay must be run by somebody else. If Channel operates both halves it is an elaborate way of learning exactly what it learns today.
### 3. Pin request and response to one fixed size — kills the asymmetry in §2 Every interaction becomes the same shape in both directions, so send, receive, and receive-nothing are indistinguishable. Costs about a cent per user per month (UNIT-ECONOMICS.md), free on an egress-free store, and it is a change to one response path plus the client request builders. Should land with the cheap-poll change, since they touch the same code.
### 4. Let a user point the app at their own proxy A SOCKS5/Tor setting is a few hours of work and costs nothing to operate. It serves the small number of people who genuinely need more than the above, using infrastructure they already trust, and we run none of it — so there is nothing for us to be compelled to hand over.
### 5. Shared CDN addressing is a defensive property worth keeping The host resolves to shared AWS addresses carrying an enormous number of unrelated sites. Blocking Channel by IP means breaking a great deal of other traffic, which raises the political cost of doing so. A dedicated IP would be a convenience for us and a gift to a censor.
Do not run our own VPN or relay nodes. It is the intuitive answer and it is backwards: whoever operates the relay sees the source IPs, so building one moves the observation point to us. That is strictly worse than today — we would be creating the record we currently do not hold, and taking on network-operator legal exposure to do it. The entire value of OHTTP is that the relay is not us.
Do not plan around domain fronting. It worked, and then AWS, Google and Cloudflare all shut it off in 2018. It is not a tool that is available any more.
Do not build a bespoke mix network. J57's anonymity-set argument applies directly: a network whose only users are Channel users identifies Channel users. Standing inside a large existing crowd beats building a small new one, which is the whole reason ECH and OHTTP are the right shapes.
One change dominates: encrypt the hostname. Until the SNI is hidden, everything else is tightening a seal on a box with the label still on the outside. OHTTP is the correct second step and the one that turns a policy promise into a structural one. Pinning sizes is cheap and answers the send-versus-receive question directly. Running our own relays would feel like progress and would be a regression.
English is the reference text; any translation is a convenience. Help is stored on this phone and never contacts anyone.