Why I built it
My laptop filled up in September. You get the warning, you spend an hour deleting things you might want later, and it fills up again in two weeks. The alternatives are a monthly cloud subscription or an external drive.
Only one machine runs out of space at a time. Sitting in a library with four other people, at least one of those laptops has a couple hundred gigabytes unused. Collectively the room has plenty of space.
So the idea was to let a group of people who already trust each other, roommates or a project team, treat their laptops as one pool. Your overflow goes onto their disks and theirs goes onto yours.
What it does
You create a group, or join one someone else made. There are two operations: store a file, and get it back.
Storing a file removes it from your disk and spreads it across the other laptops in the group. Asking for it back reassembles it from those chunks. Peers store encrypted chunks, and no server stores a copy.
How it works
What happens when you store a file
- 1
Your laptop splits the file into chunks.
The agent runs in the background on Windows and Linux.
Python
- 2
Each chunk gets a fingerprint.
It proves the chunk came back unchanged, and identical chunks are stored once.
SHA-256
- 3
Each chunk is encrypted on your laptop.
The key never leaves your machine.
AES
- 4
The coordinator says which laptops in the group are online.
It keeps track of the group and never sees your files.
FastAPI
- 5
The chunks go straight to two friends' laptops.
Every chunk is on two machines, in case one is offline.
TCP sockets
- 6
Your laptop records where every chunk went.
Getting the file back means reading that list and fetching the chunks.
SQLite
Getting a file back runs the same steps in reverse. Your laptop reads its manifest, fetches each chunk from whichever holder is online, checks the chunk against its SHA-256 hash, decrypts it, and joins the chunks in order. The coordinator only hands out addresses, so chunk bytes go laptop to laptop and never pass through a server.
The hard parts
Peers go offline without warning
Every distributed storage system deals with nodes failing. Here the nodes are student laptops, and a laptop gets closed and put in a bag. At any moment a large fraction of the group is offline, with no warning and no estimate of when it comes back.
So no chunk depends on a single peer. Every chunk goes to two different machines, so one peer going offline does not block a retrieval. The coordinator watches liveness, and when a peer has been offline long enough, it arranges for its chunks to be re-replicated from the surviving copy onto a peer that is online.
If both machines holding a chunk are closed at the same time, that file is unavailable until one opens. A higher replication factor improves availability and uses more disk per peer. I used two.
Asking a friend to hold files they must not read
Nobody puts their files on a friend's laptop if the friend can read them, and nobody donates disk space if it means being responsible for whatever someone else stores there.
Chunks are encrypted on your machine before transfer, so a peer holds bytes it cannot interpret.
There is one bad failure mode. The key is stored only on your laptop, by design, so losing the laptop means losing access to those files.
Nothing forces anyone to contribute disk
Storing is useful to you and hosting is a favour to someone else, so if the system lets you, you take space and contribute none.
So I tied storage quota to donated disk. How much you may store is a function of how much you make available, and each peer's donated and used totals are visible to the group.