A day of footage
A video editor sends the day's camera files to a colourist on the same network. The files go straight across, so there is no upload to wait for.
1.0: Direct path, checked pieces
Send huge files straight to another computer.
Nothing is stored in between. Sluice moves the file directly and checks each piece as it lands.
In development, pre-1.0
Today it names this computer, checks your setup and prints shell completions. Sending and receiving arrive in 1.0.
Your system asks for less motion, so the drawing stays still. This switch plays it for this visit.
How it works
Three steps, one file, and no stop in the middle. All three arrive in 1.0; today you can check an install with sluice doctor.
Send a file
Pick a file or a folder. Sluice reads it where it is, so a large file needs no second copy before it moves.
1.0: send and folders
Share one code
The sender gets a ticket: one line of text with the address and the file's fingerprint. Send it however you like. Keep it private, because anyone who has it can fetch the file.
1.0: the ticket
Receive it
Paste the ticket on the other computer. Every piece is checked before it is written, and a dropped link resumes at the last checked piece.
1.0: checked pieces, resume
What works today
Three commands work: sluice id, sluice doctor and sluice completions. send and recv are 1.0 and do not exist yet. The CLI README lists every check, exit code and JSON field.
doctorWorking today
ok version sluice 0.1.0 for x86_64-unknown-linux-gnu, running on linux
ok home /home/you/.local/share/sluice, from SLUICE_HOME
ok access only this user can reach the home
ok layout version 1
ok lock free
ok key 32 bytes, readable only by this user
ok space 7.7 GiB free (8307675136 bytes)
skipped transport the transport checks are not built yetReal output on a fresh home. The home path is the example one.
send and recvPreview of 1.0
$ sluice send ./render.movsluice1k4t… 24.0 GB $ sluice recv sluice1k4t… -o ./render.mov9.6 GB of 24.0 GB 40% block 585,937 verifiedA sketch of the 1.0 output, not a recording.
Where it helps
Four jobs where a stop in the cloud costs time, money or privacy. Each one names the 1.0 feature it uses.
A database backup
A nightly dump goes to a server in another building. Every piece is checked as it lands, and a dropped link picks up at the last checked piece.
1.0: Resume, checked pieces
A recording, still growing
A sound engineer shares a session while it is still being recorded. The other side can read up to the last segment that checks out.
1.0: Live transfer
One part of a huge file
A researcher needs one range from a large archive. Only that range crosses the network, and the rest stays where it is.
1.0: One byte range
Compared with uploading to the cloud
Sluice is not a storage service. The file goes from one computer to the other, and the middle keeps nothing.
| Question | Sluice | Upload, then download |
|---|---|---|
| Where the file waits | SluiceNowhere. It lands on the other computer. | Upload, then downloadOn the provider's servers. |
| Account | SluiceNone. | Upload, then downloadUsually one. |
| Size limit | SluiceNone from Sluice. Your disk is the limit. | Upload, then downloadUsually set by a plan. |
| Checked on arrival | SluiceEvery piece, against the file's fingerprint. 1.0 | Upload, then downloadUsually the provider checks its copy. Your two ends do not check each other. |
| After a dropped link | SluiceStarts at the last checked piece. Target: first new byte within 2 s. 1.0 | Upload, then downloadOften from the beginning, unless the service offers resume. |
Sending is 1.0 and is not built yet. A target is marked; the rest describes the design. The performance page has the method and the scenarios.
Questions
The short answers. The specification and the roadmap go further, and contributing says how to help.
Is it free?
Yes. The code is Apache-2.0 or MIT. You pay only for hardware and for any relay you run.
Does it work over the internet, or only at home?
Both, in 1.0. On one network it connects directly. Across the internet it tries a direct path first. If that fails, it can use a relay you run: a server that forwards the data.
Is it safe? Who can see my files?
Only the two computers keep the file. The connection is encrypted, and a relay you run passes data without storing it. A ticket is a secret: anyone who has it can fetch the file.
What works today?
sluice id, sluice doctor and sluice completions. Sending and receiving arrive in 1.0.
Do I need a server?
Not on one network. Across the internet, yes: a relay you run, which the two computers use to meet and punch a path to each other. Set as a meeting point, it fits on the smallest server and the file goes direct. Set as a full relay, it also carries the transfers that cannot go direct. Either way it never keeps the file.
What happens if the connection drops?
In 1.0, the transfer resumes at the last checked piece. The target is the first new byte within 2 s. Checked data is not sent again.
How is it different from the cloud?
The file goes straight to the other computer. There is no upload to a company's storage, no account and no plan limit. You keep the only copies.
How can I help?
Try doctor and say what it prints. Read the spec or the roadmap, or open an issue. Contributions and hard questions are both welcome.
Under the hood
The short version for engineers. The full detail is in the spec, the threat model and the decision records.
- QUIC
- An encrypted transport that runs over UDP and carries many streams at once. It keeps going when the network under it changes. the spec
- BLAKE3
- A hash tree describes the file. Every 16 KiB block (16,384 bytes) is checked against it before it is written. static content
- Hole punching
- Two computers swap addresses through a relay, then send to each other at the same time, so their routers open a path and the file skips the relay. ADR 0028
- Meeting point
- The relay with a 64 KiB/s limit per computer. Enough to set up a direct path, too slow to carry files, so the smallest server runs it. the meeting point recipe
- Relay
- A server you run. It sets up every connection across the internet, and as a full relay it also forwards the bytes when a direct path fails. It starts closed and serves only the endpoint ids you allow. the relay README
- Endpoint id and ticket
- An endpoint id names a computer's key. A ticket carries that id, an address and the file fingerprint. Anyone with a ticket can fetch the file, so share it privately. the ticket format
What 1.0 adds
None of these is in the binary today. Sending and receiving arrive in 1.0; the performance method says which numbers are targets and which are measured.
Verified blocks
Every 16 KiB block is checked against the file's BLAKE3 tree before it is written. A damaged block never reaches the output.
1.0
Read while it is written
Send a file that is still growing. The sender adds each segment to a signed log, and the receiver reads up to the last segment that checks out.
1.0
One range, not the file
Ask for a byte range and only that range is transferred. The rest of the file stays where it is.
sluice recv <ticket> --range 4G:4.1G1.0
Resume where it stopped
After a dropped link, the next attempt starts at the last checked range. Target: the first new byte within 2 s.
1.0
No second copy
The file is read where it is. The store keeps a reference, not a duplicate, so large files need no second copy of their data.
1.0
How the path is chosen
Direct first, your relay to meet, and the relay for data only if you allow it the speed.
- Direct path
- Tried first: local discovery, port mapping and hole punching over QUIC. Only the two ends hold the file.
- Meeting point
- Your relay, used to swap addresses and time the hole punch. Its low limit keeps it to that job, so the smallest server is enough.
- Relay
- The same image with a higher limit. It carries the whole transfer when hole punching fails, starts closed and relays only the endpoint ids you list.
- No relay, no fallback
- n0's public relays and DNS discovery are off. Until you name a relay, Sluice has none, and a transfer that cannot go direct fails instead of going somewhere else.
Read the specification, the threat model and the decision records.
Run your own
One container, built from this repository, run one of two ways. As a meeting point it carries no file bytes once the path is direct. As a full relay it carries the transfers that cannot go direct, and their bill.
meeting pointREADME
docker build -f docker/relay/Dockerfile -t sluice-relay docker
docker run -d --name relay -p 443:443 -p 80:80 -p 7842:7842/udp \
-v "$PWD/certs:/etc/relay/certs:ro" \
-v "$PWD/docker/relay/meeting-point.toml:/etc/relay/relay.toml:ro" sluice-relayfull relayREADME
docker build -f docker/relay/Dockerfile -t sluice-relay docker
docker run -d --name relay -p 443:443 -p 80:80 -p 7842:7842/udp \
-v "$PWD/certs:/etc/relay/certs:ro" sluice-relay- The relay starts closed. Add the endpoint ids that may relay through it before a transfer will.
- A full relay ships with no speed limit. Set
[limits.client.rx] bytes_per_secondfrom what the host can spare: a relayed transfer crosses it twice. - Both need a certificate. The README lists the two files the image mounts and the commands that make them.
Built in the open
The wire format, the threats, the decisions and the way performance is measured are in the repository, not on this page.
- SpecificationThe wire format, the ticket, the live log and the test vectors.
- Threat modelWhat Sluice defends against, and what it does not.
- Architecture decisionsOne record per decision that is not obvious from the code.
- PerformanceThe method, the scenarios, and what each number depends on.
- Install and verifyThe archive names, and the attestation check to run before you do.
Targets, not measurements
8 Gbit/s on a 10 GbE LAN, within 10% of iperf3. Under 250 MB RSS during any transfer. None of these has been measured yet.
Cold start to a printed result is under 30 ms, and it is checked on every pull request. There is no telemetry: no code sends any.