How a file crosses from phone to PC

What Geonne does

It is for the moment at a PC bang, an office or a school when a photo on your phone has to reach the PC in front of you, or a PDF that landed on that PC has to get onto your phone. The usual answers are a messenger's send-to-myself or email, which means the file sits on someone else's server and you sign in to your accounts on a shared machine. Geonne does neither.

The two browsers find each other and connect directly, and the file goes only across that link. The technology is WebRTC, the same thing video calls use. Our server only holds one short code for a moment so the two devices can find each other, and there is a way (direct, without a server) that skips even that.

One device can both send and receive. The sender adds files and presses prepare, a six-letter code and a QR code appear, the receiver types the code or scans the QR, the link comes up and the file goes over. Received files land in the receiving browser's download location.

The rules browsers agreed on

Browser-to-browser connections are an IETF standard (RFC 8825 and RFC 8829). Before connecting, the two devices must exchange each other's address and key once. That exchange is called signalling, and the standard deliberately leaves its path open, which is why every service does it differently. Geonne offers two paths: a six-letter code mailbox and a pair of QR codes.

To learn its own address a device asks a public STUN server (RFC 8489). A device behind a router does not know how it looks from outside, so it asks, and no file goes that way. Geonne uses the STUN address Google publishes. We could not find a document where Google states terms of use for that server, so it is widely used but not promised, and the app is built so that a connection on the same Wi-Fi still works if STUN never answers.

The standard also allows a TURN relay for when a direct link fails, and Geonne does not use one. A relay means the file passes through a server and somebody pays for that. Two devices in the same room should not need a relay, and we chose to say so plainly when a link fails rather than quietly route files through a server.

Once connected, files travel over a DataChannel (RFC 8831). It is encrypted with DTLS, so another device on the same Wi-Fi cannot read along, and the key fingerprint is checked against the one exchanged during signalling, so nobody without the code can step in.

This app's exact rules

This section describes what the code actually does, in order. When the sender presses prepare, the browser builds a connection signal (SDP) and collects candidate addresses. Collecting stops after 3 seconds and proceeds with what it has. From that signal the app keeps only the four values the other side truly needs (the ICE id and password, the DTLS fingerprint, the candidate addresses) and writes them on one line. The original is usually over 1,000 characters; the line is a few hundred. Nothing is changed, only rearranged, and the receiving side unfolds it back into the standard form.

The code mailbox is a box in our server's memory. The sender's one line goes in and a six-letter code comes back; the receiver uses the code to take the line out and put its own reply line in. The box accepts only text under 8KB, so a file cannot fit by construction, and everything is deleted after 10 minutes. Nothing is written to disk or to logs. If the server restarts, it all disappears, and that is fine for this kind of data.

Files are sent in 16KB pieces. Browsers differ in how large a single message may be, so the piece size sits below all of them. The sender pauses when its buffer fills, and the receiver collects the pieces and joins them into the file to save. When the receiver has everything it tells the sender, and the sending screen shows that the file fully arrived.

The limit for one file is 1GB. The receiving side collects pieces in browser memory before saving, so the real limit is that device's memory. On the day this was built it worked up to the size we could test on a desktop Chromium, and phones could not be measured in that environment. That is why the app suggests splitting big files when a phone is receiving. We would rather write the number this way than claim something we did not see.

Notes and links go as a single message rather than in pieces, up to 10,000 characters, and the receiver can copy them or open a link directly.

Measurement counts only how far a visit got (opened the page, pressed prepare, connected, handed everything over, clicked a sister tool). No file name, size or code is ever included.

How to use it well

Put both devices on the same Wi-Fi or the same hotspot. A wired PC at a PC bang or an office and a phone on that building's Wi-Fi are usually behind the same router and work. A phone on mobile data and a PC on a wire are on different networks and may not connect; turning on the phone's hotspot and joining the PC to it is the surest fix.

From PC to phone: make the PC the sending side, add the file, press prepare. Point the phone camera at the QR code and the receiving screen opens and connects on its own. From phone to PC: the phone sends, you pick receiving on the PC screen and type the six letters shown on the phone.

A received file goes into the download location only when you press save. Closing the page discards what was received. If several arrived, save them one by one.

On a shared PC such as one at a PC bang, remember to delete the file from the browser's download folder when you are done. Geonne leaves nothing on any server, but that PC's download folder is still that PC.

Connecting with QR codes alone

This path skips the code mailbox. The sender shows the connection signal as a QR code, the receiver scans it and shows its reply as another QR code, and the sender scans that one. On this path our server receives nothing.

One QR code carries up to 700 characters, and the reduced signal normally fits. If it does not, it is split across several codes and the scanner collects them in order. The screen shows how many bytes the original was, how many characters it became and how many cells the QR code has.

The second step, getting the reply back to the sender, needs a camera on the sending device. Laptops usually have one and desktops often do not. There is a paste field for the reply, but a few hundred characters are hard to carry by hand, so on such a PC the code mailbox is the right path. We kept this path because there should be one way that works with no server at all.

When it does not work

If it stops at connecting and then says the connection did not go through, the network is most likely blocking devices from reaching each other. Cafe and school Wi-Fi often has a setting (AP isolation) that keeps guests apart, and company networks sometimes block UDP. Joining both devices to a phone hotspot usually clears it.

If a code is reported as not found, check that the sending screen is still showing it. Codes vanish after 10 minutes, and if the sender closed the page there is nothing to connect to. If the screen says it could not reach the mailbox, our server is briefly down; switch to the direct connection, which needs none.

If a large file stalls while receiving, the receiving device is usually short of memory, phones especially. Send the file in parts, or make the PC the receiving side.

On Safari (iPhone) pressing save sometimes opens the file in a new tab instead of downloading it. Use the share button there and choose Save to Files. If the browser has WebRTC switched off (some privacy settings do), preparing the connection stops, and the screen says so.

This tool is for two devices in the same place. To send to someone far away, a service that stores the file is the right one, and such services take their price for keeping it. Geonne sits on the other side of that trade.