Most peeza transfers go straight from one device to the other. When a network won't allow that, peeza's relay carries the transfer instead — encrypted bytes it has no key for, and never keeps.
peeza runs one small server, the relay, and it has two jobs. The first is introductions: before a transfer starts, it helps the two devices find each other and agree on how to connect. That part is tiny, and always free.
The second job only comes up when a direct connection is impossible — a strict NAT, a corporate firewall, a hotel or guest network that blocks device-to-device traffic. Then the relay forwards the transfer between the two devices, byte for byte, so it still gets through.
direct your device ═══════════════════════▶ their device free, never counted relayed your device ══▶ relay (blind) ══▶ their device counts toward your relay nearby your device ══ same network ═══════▶ their device no internet at all
peeza always tries for a direct connection first — the relay is the fallback, not the default. And Nearby transfers, on the same network, don't touch the internet at all, let alone the relay.
A direct transfer never touches our servers, so it costs us nothing to carry — and it costs you nothing either. It is never counted, whatever its size and however often you send.
A relayed transfer is different: every byte goes through a server we pay for by the gigabyte. So relayed data is the one thing peeza meters. Only the bytes that actually went through the relay count, and the app shows how much relay you've used this month.
Every transfer is encrypted on your device before it leaves, with a key the relay never receives.
#, which browsers never send; for your own machines, it's sealed to the receiving device's own key.To route and meter a transfer, the relay does see some metadata — which devices are talking, and how many bytes went through — never the contents. The full mechanics are on the tech page, and exactly what the relay stores is in the privacy policy.