WebRTC data channels and what “direct transfer” means

An RTCDataChannel is a browser capability for exchanging data within a WebRTC connection. Mándamele creates one labelled “mandamele” and requests ordered delivery. It is not used for audio or video: it carries text messages, file metadata, binary blocks and small readiness messages. The interface only becomes ready after both endpoints have opened the channel.

The application does not invent a network transport from scratch. It delegates negotiation and transport to the browser’s RTCPeerConnection, then adds a small protocol to distinguish text, file start and file completion. This makes the flow possible inside a web page, but it also inherits the browser and network restrictions that apply to WebRTC.

Two browsers cannot find each other merely because they opened the same website. They need to exchange session descriptions and connectivity candidates. In Mándamele, a WebSocket connects each browser to the Pase Durable Object. The service forwards SDP offers, SDP answers and ICE candidates to the approved participant. It does not interpret those messages in order to rebuild a file.

Signalling also communicates creation, joining, closure, errors and pings. It is accurate to say that the service participates in establishing and maintaining the session. It would be inaccurate to say that no server is involved at all. The relevant distinction is that, once the DataChannel is available, code sends content through it rather than the signalling channel.

In the current implementation, “direct” means browser to browser over the route selected by WebRTC, with no deliberate upload of text or files to the Worker, Durable Object, database or object storage operated by Mándamele. There is no transfer upload endpoint and no fallback that turns a file into an HTTP request when WebRTC fails.

It does not mean that devices are physically joined by one cable, that no network operator transports packets, or that the receiver cannot save a copy. It also does not promise network anonymity. The service and infrastructure providers process technical information required to operate and protect the service, while access networks handle traffic and addresses as part of their normal role.

Most devices sit behind NAT or a firewall. RTCPeerConnection uses ICE candidates to try possible paths. Mándamele configures a Google STUN service on port 19302. STUN helps a browser discover how its connection appears externally; it is not the file store and it is not a content relay configured by this application.

TURN can solve some cases by relaying content when no acceptable direct path exists, but Mándamele does not configure TURN because it is outside the MVP scope. Two browsers that work on a home network may therefore fail in a company, hotel, VPN or particular mobile network. The missing fallback is a deliberate limitation that should be visible rather than disguised.

The code creates a standard RTCPeerConnection and does not disable security built into the browser. WebRTC negotiates protected transport inside that browser implementation. Mándamele does not add application-level encryption, a file password, manual fingerprint verification or a key independent of the Pase. We therefore do not describe it as a specialised cryptographic vault.

For a user, it helps to separate two questions: whether the file is uploaded to Mándamele servers, and whether it needs extra protection before being sent. The answer to the first is no in the implemented flow. For especially sensitive material, encrypting the file with a suitable tool and sharing the password through another channel can still be appropriate.

The browser does not send a 40 MB file as one message. It first checks the 50 MB limit, describes size, name, MIME type and chunk count, then loops over 64 KiB blocks. Because the channel is ordered, the receiver can rebuild the Blob in the expected sequence. Incoming metadata also has explicit length and consistency limits.

The sender watches the DataChannel buffer. Above 1 MiB it waits for the low-buffer event around 512 KiB before continuing. That mechanism reduces bursts and supports progress reporting, but it does not guarantee speed. CPU, memory, network quality, suspended tabs and receiver capacity still affect the outcome.