What is a blind relay?

Architecture, not promises

Most privacy claims are policies: "we don’t log", "we don’t look". A policy depends on behaviour, and behaviour can change — a subpoena, an acquisition, a bad quarter. A blind relay makes a different kind of claim: the capability itself is absent. If the box has no decoder, no demuxer, and no code that parses the payload, then reading the traffic isn’t a temptation being resisted — it’s a feature that was never built.

The useful mental model is postal: a relay may read the envelope — where these bytes need to go — but never the letter inside. For a video stream carried as MPEG-TS, the envelope is a handful of structural bytes at the head of each packet; the letter is the picture and sound.

The constraint cuts both ways, and it’s worth saying so: a relay that can’t read the stream also can’t transcode it, can’t build a quality ladder, can’t stitch anything into it. Most streaming infrastructure re-encodes video as a matter of course — and re-encoding requires decoding, which means the server has seen the picture. Choosing blindness means declining that whole toolbox. A no-logs policy asks for your trust; a missing decoder doesn’t need it.

None of this is specific to Twiga — blind relaying is a stance any forwarding system could take. What varies is whether the operator is willing to give up the toolbox.

In Twiga

The relay between you and your IPTV provider is blind in exactly this sense. There is no FFmpeg and no video decoder anywhere on it; the server reads only the framing bytes it needs to forward the stream, and the payload passes through untouched. What you watch isn’t something the server declines to record — it’s something the server cannot know.

What the byte path does keep is deliberately boring: a timestamp and a token — see access log. Decoding happens in your browser, after the bytes have left our hands. The privacy is a property of the wire, not a promise on a page.