The short version
The receiving app compares each file with the size the sender announced, and with the sender’s SHA-256 when the sender provides one. A SHA-256 is a short fingerprint worked out from a file’s bytes, which changes if any byte changes. A file that fails either check is deleted and the transfer stops. When every file passes both, the app shows a mark that says so, which means the files arrived intact, not that they are safe to open.The size check
Every receiver runs this check on every file. The sender announces each file’s size before its first byte, and when the sender marks the file as finished, the receiver compares what arrived with that size. The two must be equal. A file that is short was cut off, and a file that is long was not the file the sender described. Either way the receiver discards the file, tells the sender why, and stops the transfer, so files queued behind it do not arrive either. Files that finished before it are kept. See a file did not appear at all. Floe Desktop andfloe receive do not wait for the end of a file that is too long. They stop at
the first piece of data that would take a file past its announced size, so a sender cannot fill
the disk.
A browser receiver that is given no size at all accepts the file as it stands. One given a size
it cannot read, such as a negative number, stops the transfer before it keeps any data. Every
current Floe sender announces a size.
The SHA-256 check
The size check cannot see a file whose bytes changed while its length did not. The SHA-256 check can. The sender computes a SHA-256 of each file as it sends it, and sends that right after the file’s last byte. The receiver computes its own SHA-256 of what arrived and compares the two:- Floe Desktop and
floe receivecompute it while they write the file, and compare before the file takes its final name. They never read the file back from disk. - The web app computes it once the file’s last byte has arrived, on the copy it holds for you to save. The status reads “Verifying file 2 of 3” while it works.
floe receive delete it before it has
its final name, the web app discards it, the sender is told that a file did not match, and the
transfer stops. Files that finished before it are kept. A SHA-256 that arrives but cannot be read
counts as a mismatch, not as a missing one. For what each side shows, see the troubleshooting
entries for the browser,
the command line, and
the desktop app.
Senders provide a SHA-256 from floe 1.11.0, from Floe Desktop 0.3.0, and from the web app at
floe.one. An older sender provides none, and the receiver then relies on the size check alone.
Floe never shows the SHA-256 itself, and there is nothing for the two people to compare. Each app
shows only whether every file matched.
When a browser runs out of time
A browser computes the SHA-256 in the background, and with a very large file or a slow device the file can be finished before its SHA-256 is. Floe then lets the file through unchecked rather than fail a transfer whose bytes all arrived:- A browser that is sending waits for a file’s SHA-256 at most 45 seconds after the file’s
last byte, then sends the file without one. It cannot wait longer, because Floe Desktop and
floe receivegive up on a transfer that goes 60 seconds without data. - A browser that is receiving with more files to come checks a file for at most 90 seconds, then keeps it unchecked so the next file can start. The sender stops waiting for the next file to be accepted after 120 seconds. The last file of a transfer has nothing waiting behind it, so it gets as long as its size needs: the time the file would take at 10 MB per second, plus 30 seconds.
Delivery confirmation
A sender can finish sending before the receiver has finished saving. The last file may still be crossing the connection, or the receiving app may still be checking it and moving it into place. So what “sent” means depends on whether the receiver reports back.
On the first two rows and the last, the finished state is the receiver’s word: the files are saved
on the other device, or held by the receiving page, ready to save. It reads
Sent in the summary of
floe send, “Sent 3 items” in Floe Desktop, and “ALL 3 FILES ARRIVED” on a request link’s page. On
the two rows between, it means the data left your device, which is not the receiver’s word.
Where the sender waits for the receiver’s word, the wait has no time limit of its own: it lasts
as long as the connection does. If the receiving device vanishes instead of answering, floe send
and Floe Desktop give the connection up about 30 seconds after its last packet. The send then ends
as a failure, never as a success. See the troubleshooting entries for
the command line
and
the desktop app.
What you see in each app
When every file of a transfer passed the SHA-256 check, the app says so, on both sides where it can. No app shows the SHA-256 itself. In these docs this is the SHA-256 matched mark.
The web app’s main page and Floe Desktop draw the check mark without words. A screen reader reads
it as “SHA-256 matched”. A request link’s page writes a sentence instead, and the CLI a row.
On the sending side the mark is the receiver’s report, not a check your own app made: your app
sent the SHA-256, and the other side says every file matched it. The web app’s Send page says
“All Files Sent!” as soon as the last byte leaves, before that report, so its check mark is gray
for a moment and turns green when the report arrives. See
When it finishes.
When there is no mark
The mark is all or nothing. It shows only when every file of the transfer arrived and every one matched, so a single unchecked file removes it for the whole transfer. No mark does not mean a file is damaged. Every file that was kept passed the size check, and a file that fails the SHA-256 check is deleted, never kept without a mark. A transfer finishes without the mark when:- The sender sent no SHA-256 for some file. Either it is a
floeolder than 1.11.0 or a Floe Desktop older than 0.3.0, or it is a browser that had not finished computing one when its time ran out. - The receiver is a browser that had not finished checking some file when its time ran out, or that could not run the check.
- You are the sender and the receiver is an older
floeor Floe Desktop, which reports that the files arrived but not whether they matched. - Not every file arrived, because the transfer stopped partway.
- One side is a web app that someone hosts themselves and that runs an older version. See What an older web app shows.
If a file fails a check
The receiving side names the check that failed. Files that finished before the one named are kept in every app.What the checks prove and what they do not
A file that passed both checks has exactly the bytes the sending app read and sent. That rules out a file cut short and a file whose bytes changed between the two apps. The checks also do not prove:- Who sent the file. The SHA-256 travels over the same connection as the file, so it is not a signature and says nothing about who is at the other end. That question belongs to the connection itself. See Encryption.
- That the copy on your disk is still intact. Floe Desktop and
floe receivetake the SHA-256 while they write and never read the file back, and the web app checks the copy it holds before your browser saves it. Damage that happens on your disk afterward is outside the check. See Known limitations. - That the sender chose the right file. The check covers what was sent, not what was meant.