Peergos is an encrypted file system with sharing, sync and apps built in, designed so that the server storing your files cannot read their contents, their names, their sizes, their folder shape or who you share them with. These twenty-four videos teach the model one idea at a time, in order: how a file becomes chunks and sealed blobs, how a signed pointer and writer keys make the store mutable, how the cryptree and capabilities turn sharing into handing over a key, what block access tokens and the username log add, what a server can still see, and how apps, private websites and sync sit on top. The series reads the Peergos book as it stood on 22 October 2026. Each video is about a minute. Below each one is the script and a question to check yourself with.
Made with the Video Curriculum Guide; the unit cards, recorded sources and the independent review are in the Peergos Curriculum.
1. Peergos: a server you do not have to trust
Peergos is an encrypted file system with sharing and sync whose servers cannot read contents, names, sizes, folders or contacts; it can be self-hosted and is a non-profit.
Peergos is an encrypted file system, with sharing and sync built in. The server stores your files. It cannot read them.
Encrypting the contents is the easy half. Peergos also hides the names, the sizes, the folders, and who you share with.
You can run the whole thing yourself, for nothing. And still share with everyone else.
It is open source, and a non profit. No investors. Paid for by the people who use it.
This series takes it apart one idea at a time. How files are stored. How keys work. How sharing works. And what a server can and cannot see.
Check yourself. Name three things besides contents that Peergos hides from its server.
2. Your password never leaves your device
The password never leaves the device: scrypt on password, username and a salt the home server keeps yields a login key pair and a symmetric key; the server returns a sealed bundle holding the identity key pair, social key pair and root key, which only the device can open. This unit defines key pair and symmetric key for the series.
You log in with a username and a password. The password is never sent anywhere.
On your device, the password, the username and a public salt your home server keeps go through a slow hash. Scrypt, tuned to take a moment.
Out come two things. A login key pair: a public half that names you, and a secret half that proves it. And a symmetric key: one key that both locks and unlocks.
The login key pair proves who you are to your home server, the server that keeps your data. The server hands back a sealed bundle: your encrypted login data.
The symmetric key opens the bundle, on your device. Inside: your identity key pair, your social key pair, and the key to your root folder. The server stored the bundle. It never had the key.
Check yourself. What does the server receive at login, and what does it never receive?
3. Blocks are found by their hash
Storage is content-addressed through IPFS; the client checks every hash; any node can serve ciphertext; disk or S3 sits underneath.
Underneath Peergos is a content addressed store, provided by IPFS. Every block of data is named by its hash. Its fingerprint.
Ask for a hash, get the block. Any Peergos node can serve it, if you are allowed to have it.
The client checks the hash of every block it reads or writes. A server that changes a byte is caught at once.
What is in a block? Ciphertext. The store holds sealed blobs. It never holds a plain file.
Where the blobs sit does not matter. A local disk, or any S3 compatible bucket, with no loss of privacy.
Check yourself. What does the client do with every block it reads?
4. A file is chunks, each with its own key
Files are cut into chunks of up to 5 MiB, padded to 4 KiB, and each chunk is encrypted with its own random key, so copies look different and chunks are unlinkable without the read capability.
A file is cut into pieces of up to five mebibytes.
Each piece is padded to a multiple of four kibibytes. So the server never learns the exact size.
Each piece is encrypted with its own random key.
The key is random, not derived from the contents. Two copies of the same file look nothing alike on the server.
And the pieces of one file are not linkable. Without the file's key, nobody can tell which blobs belong together.
Check yourself. Why is a chunk's key random rather than derived from the chunk, and what does the server learn about a file's size?
5. The server sees a bag of blobs under random labels
A Merkle-CHAMP maps random 32-byte labels to sealed blobs; every chunk and large folder is spread across labels the server cannot relate; the folder shape lives inside the ciphertext; each bag hangs from one root hash.
So what does a server hold for you? A map from random thirty two byte labels to sealed blobs.
The map is a Merkle champ. A hash tree that works like a dictionary. Change one entry, and only the path to the root changes.
Every five mebibyte piece of a file sits under a different label. A big folder is spread the same way.
Your folders have a shape. The bag has none. The shape lives inside the ciphertext, where the server cannot see it.
A bag has one root hash. Everything in it hangs from that one hash.
Check yourself. How many labels does a 20 MiB file occupy, and can the server relate them?
6. A pointer is a signed arrow from a key to a root
Every write is signed by a writing key pair, and each writing key has a signed pointer to its current root; updates carry previous, current and a rising sequence number; servers reject updates that do not follow; clients remember the highest; one home node orders each key's writes.
Every write you make is signed by a writing key pair. Hashes never change. Your files do. So each writing key has a pointer, a signed arrow: public key to current root hash.
An update is signed by the key. It names the previous root, the new root, and a sequence number that only goes up.
The server checks the signature and the sequence. An update that does not follow from the current root is rejected.
Clients remember the highest sequence they have seen. A server cannot quietly serve an older root.
One node is the home of each pointer. That node is where your writes line up, one after another.
Check yourself. What stops a server from serving you last week's root?
7. A writer key owns a subtree
You start with one random writing key; to let someone write to a folder, that folder gets its own key pair, pointer and bag; the guest can change only that subtree, under a quota if you like.
You start with one random writing key pair. It controls writes to your whole file system.
To let a friend write to one folder, you do not share that key. You cut that folder off, onto its own new key pair.
That key gets its own pointer and its own bag of blobs. A writing subspace.
Your friend holds the subspace key. They can change that folder. Nothing above it.
A subspace can carry a quota. A guest cannot fill your whole store.
Check yourself. What does a friend with a subspace key control?
8. The cryptree: one key opens everything beneath it
Read access is a tree of symmetric keys where a folder key decrypts its children; a file key reveals nothing about siblings; write access is a separate tree of signing keys; sharing for reading is handing over a key and the data stays where it is.
Read access is a tree of symmetric keys. Each folder's key decrypts the keys of its children.
Hold the key to a folder, and you can read everything beneath it. Peergos calls this the cryptree.
Hold the key to one file, and that is all you get. Not its siblings. Not even their names.
Write access is a second tree, of signing key pairs. The two trees are separate. Reading never implies writing.
To share a folder for reading, you hand over its key. The data stays where it is.
Check yourself. You hold the key to one file. What do you learn about the folder it is in?
9. A capability is the address and the key together
A capability names the owner key, writer key and label, carries the block token and the symmetric key, and comes in mirror, read and write grades (write adds the write key); whoever holds it can use it.
What exactly do you hand over? A capability. A small card that says where a thing is, and how to open it.
Where: the owner's public key, the writer key whose pointer to follow, and the label in the bag.
How: a token the server wants before it releases the blob. And the symmetric key that decrypts it.
Three grades. A mirror capability fetches the ciphertext. A read capability opens it. A write capability adds the write key.
A capability needs no account and no permission list. Whoever holds the card can use it.
Check yourself. What does a write capability have that a read capability does not? What does a mirror capability let you do?
10. Sharing seals the card to a friend's key
The one asymmetric step in sharing is sealing the capability to a per-friend folder to the friend's public key, with a hybrid of X25519 and ML-KEM-1024 so that recording it today is useless to a future quantum computer; later shares go into that folder; unshared files need none of this.
Sharing starts with one sealed message: the capability to a folder you made for that friend. A card works for whoever holds it. The seal to their public key is what keeps it private. Everything you share later goes into that folder.
Here is the catch. Someone can record that sealed card today, and wait for a quantum computer.
So the seal uses two locks. X twenty five five nineteen, and ML KEM ten twenty four, a post quantum scheme.
An attacker must break both. What you share today stays sealed if one of them falls.
Files you never share need none of this. Hashing and symmetric encryption are not much weakened by a quantum computer.
Check yourself. Which files are already safe from a quantum computer, and why?
11. Taking access back means new keys
A given key cannot be un-given, so revocation re-keys the shared subtree; new writes get new ciphertext and new tokens, old blobs are not rewritten, the old key opens only what it already saw, and others you shared with keep access.
You shared a folder. Now you want it back. The friend still holds the key. Keys cannot be un-given.
So the folder gets a new key. The lock is changed. Everything beneath it is re-keyed.
New writes get new ciphertext. The old blobs are not rewritten. The old key simply opens nothing new.
The friend's old key still opens what they already saw. It opens nothing you write from now on.
Only the shared subtree pays the cost. Others you shared it with keep their access. The rest of your files are untouched.
Check yourself. After revocation, what can the former friend still read?
12. A secret link keeps the key after the hash sign
The URL fragment holds the key and never reaches the server; it decrypts a sealed capability on the reader's device; links can expire, count uses, and carry an extra password; the fragment's own lock is built to resist a hundred years of a million GPUs at a million scrypt guesses a second.
A secret link is a URL. The part after the hash sign is the secret.
Browsers never send that part to a server. Like a note the postman never reads. So the server hosts the link and cannot open it.
The server returns a sealed capability. The fragment decrypts it, on the reader's device.
A link can expire. It can allow a fixed number of uses. It can also need a password.
The fragment is a password too. Its lock is built to take a hundred years to break, with a million GPUs each doing a million guesses a second.
Check yourself. Which part of a secret link does the server never see?
13. Even the raw blobs need a ticket
Your blocks are paired with a block access token, a secret from which a node signs each request (time-limited, naming the block, tied to the node's key, not lendable); one token per chunk, inline and mirror kinds; a node that fetched a block with a valid token can serve it on under the same token.
On plain IPFS, anyone who knows a hash can fetch the block. Ciphertext is still a leak. Sizes, and which blocks go together.
Peergos pairs your blocks with a block access token. No valid token, no block. A node that fetched a block with a valid token can serve it on, and enforces the same token.
The token is a secret. From it, your node signs each request. Time limited, naming the block, tied to your node's key. That signed request cannot be lent. A ticket with your name on it.
Every five mebibyte chunk has its own token. So the server still cannot tell which blobs make one file.
Two kinds. An inline token, for one block. A mirror token, for a whole user, so another server can copy everything you own.
Check yourself. What cannot be lent: the token, or the request signed with it?
14. What the server can still see
A home or mirror server sees total space (rounded up by padding) and the count, expiry and use counts of secret links, plus by construction which writer keys exist and when they write; not names, sizes, folders, thumbnails or contacts; access patterns are the planned Tor work.
Be honest about the leftovers. A home server, or a mirror, still sees some things.
How much space you use in total, rounded up by the padding.
How many secret links you have, with their expiry and use counts. And, by construction, which writer keys exist and when they write.
What it does not see: file names, sizes, folder shapes.
Not thumbnails. Not who you share with. Access patterns are the open item. The plan is a Tor hidden service.
Check yourself. Name two things the threat model says the server can see and two it cannot.
15. Usernames live in one append-only log
A username is a signed claim with an expiry and a home node id, taken first come first served through the PKI node, mirrored on every node, with mirrors rejecting anything that is not append-only.
A username maps to an identity public key. The map is a global, append only log. A ledger copied to everyone.
To take a name, you sign a claim. It carries an expiry, and the id of your home server.
Names are first come, first served. That needs consensus, so one node, the PKI node, confirms each claim.
The log is mirrored on every Peergos node. Mirrors reject any update that is not append only.
Mirrors do not just notice a rewrite. They refuse it. Like a key transparency log, a public record of keys, but used as the source of truth.
Check yourself. What does a mirror do with an update that changes an old mapping?
16. Your home server is where your pointers live
Each user's home server runs an IPFS node and holds their pointers and incoming requests; you can talk to any server because writes are forwarded to the home node, and what travels is ciphertext and a signed pointer; users on different servers share directly; no central server stores or watches your data; a home server can be at home.
Every user has a home server. It runs an IPFS node, holds your pointers, and keeps the requests other users send you.
But you can talk to any Peergos server. Your home has a forwarding address.
A write is forwarded to your home node over an encrypted peer to peer stream. What travels is ciphertext and a signed pointer. The server that forwards it learns nothing it can use.
Users on different servers share with each other directly. No central server stores your data or watches it move.
And a home server can be at home. A small machine, on your own connection.
Check yourself. What does the server that forwards a write actually see?
17. Moving home takes your identity with you
Identity is not tied to a server; migration copies the data and updates the claim, friends do nothing, and a mirror keeps a continuous copy of your data (and your login data if asked).
Your identity is not tied to any server. The name, the keys, and the files are yours.
To move, you copy your data to a new home server.
Then you update your claim in the log: this is my home now.
No one you share with has to do anything. Links keep working. Friends stay friends.
A mirror does the same copy continuously. If your home goes down, the mirror has your data, and your login data if you asked it to.
Check yourself. What must your friends do when you move servers?
18. A follow request reveals only who it is for
A follow request is sealed to the recipient with the X25519 and ML-KEM hybrid, sent from a single-use key, held on the recipient's server and deleted after reading; it carries the capability to a folder the sender made for the recipient, who keeps it on accepting and may send one back.
To connect with someone, you send a follow request. An envelope sealed to their public key, with the two locks from before. The only thing on the outside is who it is for.
It is sent from a fresh, single use key pair. The server cannot see who sent it.
It waits on the recipient's home server, not in the public store.
The request carries a capability to a folder the sender made for you. Accept, and you keep it. Send one back, and you are friends both ways.
Once read, the request is deleted from the server. The capability lives on in your own encrypted store.
Check yourself. Which way does the capability travel in a follow request?
19. The social graph is folders
Friend lists are encrypted data; each friendship is a shared folder; files friends share appear in the newsfeed; a share is a write into your own space, so the server does not learn who follows whom; two friends reading one file is the remaining leak that Tor is meant to close.
Who are your friends? That is data, and it is encrypted like any other data.
Each friendship is a shared folder. What you share with them goes in it.
Files your friends share with you appear in your newsfeed. That feed is those folders, read together.
A share is a write into your own space. The server sees you write. It does not learn who follows whom.
Two friends open the same file. Today, that pair of reads is the one thing that could give them away. Hiding it is the Tor work.
Check yourself. What is a friendship in storage terms, and what is the one access pattern that can still leak?
20. Trust nothing you did not verify
The client checks every hash and signature, so servers can only store, serve or refuse; what remains is availability and getting an authentic client, at three levels of care.
A Peergos client checks the seal on everything that arrives. The hash of every block. The signature of every signed thing it receives.
So a server cannot alter your data, and cannot forge a pointer. It can only store and serve.
What a server can still do is refuse. Availability is the trust that remains.
The client you run is the last piece. You have to get a real copy of Peergos from somewhere.
Three ways to get one. Trust the web and its certificates. Download the app. Or build it yourself.
Check yourself. What is the one thing a malicious server can still do to you?
21. Apps run in their own origin with no permissions
An app is a folder of HTML and a manifest, run under a hashed hostname in its own process and locked down from outside requests, its calls passing through a service worker to the Peergos tab; permissions are declared in the manifest and folder access is granted in a dialog; one browser gap (WebRTC) remains, so install only trusted apps for now.
A Peergos app is a folder of plain HTML and JavaScript, with a manifest.
It runs under its own hostname, the hash of its path. Isolated from Peergos and from every other app.
Its requests go through one door: a service worker to the main Peergos tab, which checks them. A doorman. It is locked down so it cannot make outside requests.
By default an app has no permissions. It can read its own assets. Other permissions are declared in its manifest. Access to one of your folders you grant in a dialog, and can revoke.
Even the app's files never reach the server in the clear. One browser gap, WebRTC, is still open. So for now, install only apps you trust.
Check yourself. What does an app have access to before you grant anything?
22. A private website is a folder
Any folder of pages is a website, opened in the built-in browser under its own origin, shared like a folder, with nothing able to leave the page except through the same WebRTC gap as apps.
Any folder in Peergos can be a website. Put your pages in it, and it is one.
It opens in the built in browser, under its own origin, like an app.
To publish it, you share the folder. Directly, or with a secret link.
Nothing can leave the page, with the same one gap as apps. Third party tracking is impossible. Fingerprinting learns nothing.
Sites link to each other by file path. A private web, with the same locks as your files.
Check yourself. How do you publish a private website?
23. Sync copies only the changed chunks
Sync keeps a local and a Peergos folder the same in both directions, sends only changed chunks, treats deletes as a choice, serves many devices, and since 2025 unrelated concurrent writes no longer fail (same-file conflicts remain conflicts).
Sync keeps a local folder and a Peergos folder the same. Both directions.
Change a big file, and only its changed chunks are sent. The rest of the file stays where it is.
Deletes can follow in either direction, or neither. You choose.
Several devices can sync the same folder. A laptop, a desktop, a phone, each holding a copy.
Two devices write different files at once? Since twenty twenty five, that no longer fails. The same file changed in two places is still a real conflict.
Check yourself. A 1 GB file gets one byte changed. What is sent? And what still counts as a conflict?
24. Where Peergos stands
Twenty releases in 2025 brought post-quantum sharing, native apps, sync and much faster folders; the second audit, in 2024, found nothing high; it is a user-funded non-profit; 2026 is polish, usability and iOS.
In twenty twenty five Peergos shipped twenty releases. More than double the year before.
Post quantum sharing. Native apps for Windows, macOS, Linux and Android. Folder sync, and folder loading up to a hundred and fifty times faster.
A second security audit, in twenty twenty four, by Radically Open Security. No high or elevated findings. Two moderate, six low. All fixed.
It is a non profit with no investors, funded by its users. Paying customers tripled in the year.
The stated plan for twenty twenty six: polish, usability, iOS, and deeper OS integration.
Check yourself. Who audited Peergos in 2024, and what did they find?
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime