Connectivity: nearby, WebRTC, TLS, routing and ICMP

Browsers have no general interface to open arbitrary TCP listeners or raw ICMP sockets. The direct browser route uses a WebRTC data channel. Signaling helps the endpoints set up the connection; it is not itself the file data path. With TURN, data is forwarded: that is a relay, even if the client uses the same WebRTC family for it.

A direct route is only taken once the other side has proven it is the intended pipeit device. Native clients can offer concrete listeners of their own. On the online route, candidates are bound to devices, fingerprints, request and expiry, signed and exchanged encrypted. The backend server does not scan networks at random. The client checks the offered authorized endpoints with bounded parallelism and time budgets.

The native TCP route checks TLS 1.3 and the exact bound peer identity. A random challenge with device signatures follows, bound to the respective check or transfer context. An open port, a successful ping or a completed socket connect is not enough to count as a verified pipeit peer.

Nearby: Wi-Fi Aware, LAN and local discovery

In the same room the apps find each other first: over Wi-Fi Aware without a router, or over the shared Wi-Fi or LAN, using Bluetooth and local network discovery to announce themselves. Discovery only names a candidate; the device still has to prove its identity with the same TLS 1.3 handshake and device signatures as on any other direct route before a file flows.

Routed networks are no special format

If an offered address with a matching listener is reachable across routers and the release is valid, the same TLS file route can be used. NAT needs an actually reachable mapping or another supported route. A private IP alone proves neither reachability nor a shared LAN. Firewall release, listener and confirmed identity have to fit together.

The ICMP path for locked-down Linux hosts

The native IPv4 ICMP path builds a reliable bounded byte stream on ICMP echo request and reply; the same TLS identity check runs over it. That is not simply “throwing file bytes into pings”. Roles, session binding, ordering, acknowledgements, retransmission and resource limits are part of it. It has to be set up explicitly on suitable Linux endpoints and needs targeted operating-system rights. It is IPv4-only, runs between hosts that can exchange echo packets, and does not tunnel through NAT, CGNAT or firewalls that block ICMP.

Local pairing without an online account

Native clients can additionally pair with a separate local identity, independent of any account. For that, signed peer profiles are exchanged deliberately and the fingerprints compared independently. The difference from the online route is the source of trust and coordination, not skipping authentication or content verification.