Skip to main content
Floe never moves your file. It introduces two devices, they build a connection between themselves, and the file crosses that connection, not the server. Once both devices are there, the server’s part takes a few seconds.

​
The short version

Floe’s signaling server, the server that introduces devices, puts the two devices in a room: a private meeting point for one transfer, with one sender and one receiver. It passes their connection details along and then drops out, so no file ever goes through it. A room code works for 10 minutes at most, and a share link works while its sender is still connected.

​
Step by step

1

You create a transfer

Your device makes up a random room id and joins that room. You share a link containing it, or a three-word room code that maps to it. A link can also hold a link key, which your device makes too and the server never receives. A room code holds none.
2

They join the same room

The server now has two devices in one room, and tells the first one that someone arrived.
3

The two devices introduce themselves

Each device sends the other a description of how to reach it, with a list of its network addresses, and the server passes these along. Each then tries to find a path to the other.
4

The connection opens and the server drops out

Each side that holds the link key proves it over that connection, and then every byte of the file travels over it. None of it goes back through the server.
Steps 1 to 3 all pass through the server. Step 4 does not. Who holds a link key, and what each app does with the proof, is under What the link key checks. A request link, a link made in Floe Desktop for someone to send you files, runs the same steps with the roles the other way around. The Floe Desktop that made the link is in the room first and receives. The person sending joins when they press the send button on the link’s page or run floe send --to. On most networks the path found in step 3 is direct, device to device. When a firewall or a carrier’s network makes that impossible, the connection runs through an encrypted relay instead. See Direct connections and Relay fallback.

​
What the server does

  • Puts two devices in a room and assigns roles. A room has two seats, one for the sender and one for the receiver. For a room code or a share link, the first device to join sends and the second receives. A request link keeps the receiving seat for the Floe Desktop that made it, and the person sending joins second.
  • Passes the connection-setup messages between them.
  • Hands out time-limited credentials for the relay, when one is configured.
  • Turns a room id into a three-word room code when floe send or Floe Desktop asks for one, and back into the room id for a receiver who types it, for 10 minutes at most. See How long a code and a link last.
  • Adds the size of a finished transfer to one public running total, if the receiving side is willing. That is a single shared number, and every receiving app can switch it off. See Security and privacy.

​
What the server never does

  • Touch file data. Not in transit, not at rest, not in any form.
  • Receive a link key. It stays in the part of the link after the #, and an app joins with the room id alone.
  • Store file names, contents, or a record of what you sent or to whom.
  • Keep a room once its session is over. The room is dropped when the last connection to it closes. A room code stops working sooner, as soon as the receiver joins. While a code lasts, it maps to nothing but a random room id. What the server holds about the devices themselves, and for how long, is in Security and privacy.
  • Connect the byte total to you. It is one number with no per-user or per-transfer rows behind it.
A request link is the one room that outlives its connections. The server holds it for the Floe Desktop that made it until it ends, and remembers for 24 hours afterward that it was used or ended. What it keeps, and for how long, is listed under Security and privacy.

​
A room holds exactly two people

The room is the transfer. It has two seats, one for the sender and one for the receiver, and a third device that tries to join is turned away. The web app shows Link Invalid, while floe receive and Floe Desktop say room is full (someone else may already be receiving). The seat frees again once that device disconnects and the server notices. That takes up to about a minute if the drop was not a clean one. Whether the transfer survives that gap depends on who is sending:
  • The web app holds its room open for the receiver to come back from the same network.
  • floe send and Floe Desktop end the transfer as soon as the receiving side goes.
A freed seat does not let just anyone in. After a sender and a receiver start connecting, the room accepts only their two networks. A device on any other network is turned away as if the room were full, for as long as the room exists. A network counts once a device on it has sent a connection-setup message through the room, as a sender and a receiver do the moment they start connecting. Joining alone does not count, so a sender whose network changes while it waits for its receiver is not counted twice. Devices that share one public address, such as two people behind the same router, count as one network and are not told apart. Limits says exactly what counts as one network. The same rule turns away one of the two people themselves if their network changes after they have started connecting, for example from Wi-Fi to mobile data. They need a new link. See a device that changed networks is refused. A request link differs in one way: it is used up. Once someone connects through it, the room seals, and nobody else can take the seat while their request or their drop lasts. When the drop ends, a later sender is told the link has already been used. A request that is declined or not answered in time does not use it up: the link can wait again for the next sender. On Floe Desktop 1.1 and later, a sender that fails the link key check does not use it up either, until the fifth one closes it. For a second recipient, start a second transfer. A room code is the three words that floe send and Floe Desktop show beside their link. The web app’s Send page makes a link and no code. A code carries no link key, so a receiver who joins with one has no check. A code works for 10 minutes at most, counted from the moment it is made, and the server retires it sooner when any of these happens first: Looking a code up does not use it up. A receiver whose attempt fails before it takes its seat, for example because the folder it was told to save in cannot be used, can try the same code again. Nothing extends the 10 minutes. A sender who is still waiting after that can be reached only through the link. A code that has stopped working looks the same whatever retired it: floe receive prints Error: could not resolve "olive-tiger-castle": code "olive-tiger-castle" not found: it was already used, the sender left, or it expired (a code lasts 10 minutes at most), and Floe Desktop shows “That code wasn’t recognized”. A share link has no clock of its own. It carries the room id, and a link key when it has one, so it works for as long as its sender is still in the room:
  • A link from the web app’s Send page works while the sender’s tab stays open and connected.
  • A link from floe send or Floe Desktop works until that send finishes, fails, or is canceled. Neither sets a limit on how long it waits for a receiver. Such a link still serves one receiver only: the send ends when its receiver leaves, even a receiver that only opened the link and closed it again.
The server does not use a link up when it is opened. A device that opens it while a receiver is connected is turned away because the second seat is taken, not because the link was opened before. Once the sender has left, the link leads to an empty room. The web app says “The sender is not connected”, and floe receive and Floe Desktop say this code or link is no longer active; ask the sender for a new one. A request link follows its own rules: its end time is chosen when it is made, and one accepted drop uses it up. See how a request link ends.

​
Where to go deeper

HTTP API

The endpoints behind room codes, relay credentials, and the byte counter.

Transfer protocol

What the two devices say to each other once the connection is open.
Last modified on November 3, 2026