Idea. 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.

Why it matters. It frames what every later unit is protecting.

Context assumed. Nothing.

Metaphor. None; a framing unit.

Misconception. "Encrypted" means only the file contents. Addressed at beat 2.

Visual language. Server box, hidden fields, house, jar, four blocks.

Target length. 55 to 65 seconds.

Check question. Name three things besides contents that Peergos hides from its server.

Script:

Peergos is an encrypted file system, with sharing and sync built in. The server stores your files. It cannot read them. (Screen: a server box; a locked file inside it.)

Encrypting the contents is the easy half. Peergos also hides the names, the sizes, the folders, and who you share with. (Screen: the file's name, size and sharing list, all hidden.)

You can run the whole thing yourself, for nothing. And still share with everyone else. (Screen: a home server under a house.)

It is open source, and a non profit. No investors. Paid for by the people who use it. (Screen: no investor icon; a jar of coins from users.)

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. (Screen: four blocks: storage, keys, sharing, servers.)

Idea. 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.

Why it matters. It is how an account exists without the server ever holding a secret.

Context assumed. Unit 1.

Metaphor. A sealed bundle the server stores but cannot open.

Misconception. The server checks your password. Addressed at beat 1.

Visual language. Laptop, hash funnel, key pair, bundle; the opened bundle with three contents.

Target length. 55 to 65 seconds.

Check question. What does the server receive at login, and what does it never receive?

Script:

You log in with a username and a password. The password is never sent anywhere. (Screen: a username sent; the password stays on the laptop.)

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. (Screen: password plus username plus salt into a slow hash.)

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. (Screen: out come a login key pair and a symmetric key.)

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. (Screen: the login key fetches a sealed bundle from the home server.)

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. (Screen: the bundle opened: identity key pair, social key pair, root key.)

Idea. Storage is content-addressed through IPFS; the client checks every hash; any node can serve ciphertext; disk or S3 sits underneath.

Why it matters. It is why a server cannot alter data and why any server will do.

Context assumed. Unit 1.

Metaphor. Asking for a block by its fingerprint; spoken at beat 1.

Misconception. The server stores files. It stores sealed blobs by hash. Addressed at beat 4.

Visual language. Blob with hash, fetch arrow, re-hash check, disk and bucket.

Target length. 50 to 60 seconds.

Check question. What does the client do with every block it reads?

Script:

Underneath Peergos is a content addressed store, provided by IPFS. Every block of data is named by its hash. Its fingerprint. (Screen: a block of bytes; its hash label.)

Ask for a hash, get the block. Any Peergos node can serve it, if you are allowed to have it. (Screen: a hash goes in, the block comes out.)

The client checks the hash of every block it reads or writes. A server that changes a byte is caught at once. (Screen: the client re-hashes the block and compares.)

What is in a block? Ciphertext. The store holds sealed blobs. It never holds a plain file. (Screen: a block that is a sealed blob.)

Where the blobs sit does not matter. A local disk, or any S3 compatible bucket, with no loss of privacy. (Screen: disk and an S3 bucket under the node.)

Idea. 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.

Why it matters. Chunking plus random keys is what hides sizes and structure, not just contents.

Context assumed. Unit 3.

Metaphor. Cutting a file into slices and sealing each separately.

Misconception. Encrypting a file once is enough. Addressed at beat 4.

Visual language. File slices, padding tail, keys, two ciphertexts, scattered pieces.

Target length. 50 to 60 seconds.

Check question. Why is a chunk's key random rather than derived from the chunk, and what does the server learn about a file's size?

Script:

A file is cut into pieces of up to five mebibytes. (Screen: a file cut into 5 MiB pieces.)

Each piece is padded to a multiple of four kibibytes. So the server never learns the exact size. (Screen: each piece padded to a 4 KiB boundary.)

Each piece is encrypted with its own random key. (Screen: each piece sealed 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. (Screen: two identical files, two different ciphertexts.)

And the pieces of one file are not linkable. Without the file's key, nobody can tell which blobs belong together. (Screen: the pieces scattered; no line joins them.)

Idea. 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.

Why it matters. It is the shape the server actually sees, and it has no shape.

Context assumed. Unit 4.

Metaphor. A bag with no shape. Break, spoken: the bag having no shape is the point.

Misconception. Folder structure is visible to the server. Addressed at beat 4.

Visual language. Bag, hash tree, labels, root.

Target length. 50 to 60 seconds.

Check question. How many labels does a 20 MiB file occupy, and can the server relate them?

Script:

So what does a server hold for you? A map from random thirty two byte labels to sealed blobs. (Screen: a bag of sealed blobs, each with a random label.)

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. (Screen: the map drawn as a tree of hashes: the merkle champ.)

Every five mebibyte piece of a file sits under a different label. A big folder is spread the same way. (Screen: one file's pieces under unrelated labels.)

Your folders have a shape. The bag has none. The shape lives inside the ciphertext, where the server cannot see it. (Screen: a folder tree on the left; a flat bag on the right.)

A bag has one root hash. Everything in it hangs from that one hash. (Screen: the bag with one root hash on top.)

Idea. 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.

Why it matters. It is the only mutable thing in the system, so it carries all the ordering.

Context assumed. Unit 5.

Metaphor. A signed arrow that only moves forward; spoken at beat 1.

Misconception. The server decides the latest version. Addressed at beat 4.

Visual language. Key, arrow, root hash, update card, counter.

Target length. 50 to 60 seconds.

Check question. What stops a server from serving you last week's root?

Script:

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. (Screen: a public key; an arrow to a 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. (Screen: the pointer update: previous, current, sequence number, signature.)

The server checks the signature and the sequence. An update that does not follow from the current root is rejected. (Screen: the server checks the signature and the sequence.)

Clients remember the highest sequence they have seen. A server cannot quietly serve an older root. (Screen: a client remembers the highest sequence it has seen.)

One node is the home of each pointer. That node is where your writes line up, one after another. (Screen: one node holds the pointer; others ask it.)

Idea. 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.

Why it matters. It is how write access is delegated without sharing the root key.

Context assumed. Unit 6.

Metaphor. Cutting a branch onto its own key; spoken at beat 2.

Misconception. Sharing write access shares your whole account. Addressed at beat 2.

Visual language. Tree with a key, cut subtree, new key and pointer, quota.

Target length. 45 to 55 seconds.

Check question. What does a friend with a subspace key control?

Script:

You start with one random writing key pair. It controls writes to your whole file system. (Screen: one key over the whole folder tree.)

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. (Screen: a subtree cut off under a new key.)

That key gets its own pointer and its own bag of blobs. A writing subspace. (Screen: the new key with its own pointer and bag.)

Your friend holds the subspace key. They can change that folder. Nothing above it. (Screen: the friend holds the subspace key only.)

A subspace can carry a quota. A guest cannot fill your whole store. (Screen: a quota on the subspace.)

Idea. 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.

Why it matters. It is the access-control idea the whole system is named for.

Context assumed. Unit 7.

Metaphor. A key that opens every door beneath it.

Misconception. Sharing copies or moves data for the recipient. Addressed at beat 5.

Visual language. Folder tree with keys, lit subtree, dark siblings, second tree, handed key.

Target length. 50 to 60 seconds.

Check question. You hold the key to one file. What do you learn about the folder it is in?

Script:

Read access is a tree of symmetric keys. Each folder's key decrypts the keys of its children. (Screen: a folder tree where each node holds a key.)

Hold the key to a folder, and you can read everything beneath it. Peergos calls this the cryptree. (Screen: one key lights the whole subtree below it.)

Hold the key to one file, and that is all you get. Not its siblings. Not even their names. (Screen: a key to one file; its siblings dark and nameless.)

Write access is a second tree, of signing key pairs. The two trees are separate. Reading never implies writing. (Screen: a second tree of signing keys beside the first.)

To share a folder for reading, you hand over its key. The data stays where it is. (Screen: a key handed from one person to another; the data unmoved.)

Idea. 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.

Why it matters. It is the thing that is shared, linked and stored everywhere else in the series.

Context assumed. Unit 8.

Metaphor. A small card with an address and a key on it.

Misconception. Access is a server-side permission. Addressed at beat 5.

Visual language. Capability card with two regions, where and how, lit one at a time; three grades.

Target length. 50 to 60 seconds.

Check question. What does a write capability have that a read capability does not? What does a mirror capability let you do?

Script:

What exactly do you hand over? A capability. A small card that says where a thing is, and how to open it. (Screen: a capability card with empty fields.)

Where: the owner's public key, the writer key whose pointer to follow, and the label in the bag. (Screen: the where region lit: owner key, writer key, label.)

How: a token the server wants before it releases the blob. And the symmetric key that decrypts it. (Screen: the how region lit: block token, read key.)

Three grades. A mirror capability fetches the ciphertext. A read capability opens it. A write capability adds the write key. (Screen: three grades: mirror, read, write.)

A capability needs no account and no permission list. Whoever holds the card can use it. (Screen: a card checked with no server.)

Idea. 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.

Why it matters. Sharing is where long-term secrecy is at risk.

Context assumed. Unit 9.

Metaphor. Two locks on one seal. Break, spoken at beat 1: the card itself works for whoever holds it, so the seal is what keeps it private.

Misconception. Post-quantum means every part of the system changed. Addressed at beat 5.

Visual language. Card, friend's key, recorder and clock, two locks, unshared file.

Target length. 50 to 60 seconds.

Check question. Which files are already safe from a quantum computer, and why?

Script:

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. (Screen: one sealed message: the capability to a folder made for the friend.)

Here is the catch. Someone can record that sealed card today, and wait for a quantum computer. (Screen: a recorder box between the two; a clock.)

So the seal uses two locks. X twenty five five nineteen, and ML KEM ten twenty four, a post quantum scheme. (Screen: two locks on the seal: X25519 and ML-KEM-1024.)

An attacker must break both. What you share today stays sealed if one of them falls. (Screen: both locks must open.)

Files you never share need none of this. Hashing and symmetric encryption are not much weakened by a quantum computer. (Screen: an unshared file: symmetric only; already safe.)

Idea. 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.

Why it matters. Revocation is the honest cost of key-based sharing.

Context assumed. Unit 8.

Metaphor. Changing the lock after lending a key; spoken at beat 2.

Misconception. Removing a friend from a list revokes access. Addressed at beat 1.

Visual language. Friend with key, new key, old blobs kept beside new, untouched tree.

Target length. 45 to 55 seconds.

Check question. After revocation, what can the former friend still read?

Script:

You shared a folder. Now you want it back. The friend still holds the key. Keys cannot be un-given. (Screen: a friend holding a folder key.)

So the folder gets a new key. The lock is changed. Everything beneath it is re-keyed. (Screen: a new key on the folder.)

New writes get new ciphertext. The old blobs are not rewritten. The old key simply opens nothing new. (Screen: old blobs stay; new writes sealed under the new key.)

The friend's old key still opens what they already saw. It opens nothing you write from now on. (Screen: the friend's old key opens nothing new.)

Only the shared subtree pays the cost. Others you shared it with keep their access. The rest of your files are untouched. (Screen: the rest of the tree untouched.)

Idea. 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.

Why it matters. It is sharing with someone who has no account, without giving the server anything.

Context assumed. Unit 9.

Metaphor. The part of the address the postman never reads; spoken at beat 2.

Misconception. A link on a server means the server can open it. Addressed at beat 2.

Visual language. URL with amber fragment, server, sealed capability, three limits.

Target length. 45 to 55 seconds.

Check question. Which part of a secret link does the server never see?

Script:

A secret link is a URL. The part after the hash sign is the secret. (Screen: a URL with a fragment after #.)

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. (Screen: the browser sends the URL without the fragment.)

The server returns a sealed capability. The fragment decrypts it, on the reader's device. (Screen: the server returns a sealed capability; the fragment opens it.)

A link can expire. It can allow a fixed number of uses. It can also need a password. (Screen: limits: expiry, use count, 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. (Screen: a hundred years; a million GPUs.)

Idea. 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.

Why it matters. It closes the gap between "encrypted" and "unobservable".

Context assumed. Unit 4.

Metaphor. A ticket with your name on it; spoken at beat 3.

Misconception. Ciphertext can be public. Addressed at beat 1.

Visual language. Blob, ticket, three ticket fields, per-chunk tickets, two kinds.

Target length. 55 to 65 seconds.

Check question. What cannot be lent: the token, or the request signed with it?

Script:

On plain IPFS, anyone who knows a hash can fetch the block. Ciphertext is still a leak. Sizes, and which blocks go together. (Screen: a sealed blob; anyone can ask for it by hash.)

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. (Screen: a ticket paired with the hash.)

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. (Screen: the signed request: time limited, names the block, tied to the asker's key.)

Every five mebibyte chunk has its own token. So the server still cannot tell which blobs make one file. (Screen: every chunk has its own token.)

Two kinds. An inline token, for one block. A mirror token, for a whole user, so another server can copy everything you own. (Screen: two kinds: inline per block; mirror per user.)

Idea. 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.

Why it matters. A privacy claim is only credible with its leftovers listed.

Context assumed. Unit 13.

Metaphor. A short list beside the server.

Misconception. The server sees nothing at all. Addressed at beat 1.

Visual language. Server, list, crossed-out items, onion.

Target length. 45 to 55 seconds.

Check question. Name two things the threat model says the server can see and two it cannot.

Script:

Be honest about the leftovers. A home server, or a mirror, still sees some things. (Screen: a server with a short list beside it.)

How much space you use in total, rounded up by the padding. (Screen: total space used.)

How many secret links you have, with their expiry and use counts. And, by construction, which writer keys exist and when they write. (Screen: secret link counts; writer keys and times.)

What it does not see: file names, sizes, folder shapes. (Screen: crossed out: names, sizes, folder shapes.)

Not thumbnails. Not who you share with. Access patterns are the open item. The plan is a Tor hidden service. (Screen: crossed out: thumbnails, contacts; then a Tor onion.)

Idea. 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.

Why it matters. It is the one global thing in the system, and it is built so that no one can rewrite it.

Context assumed. Unit 2.

Metaphor. A ledger copied to everyone; spoken at beat 1.

Misconception. Usernames are accounts on a server. Addressed at beat 1.

Visual language. Ledger strip, signed claim, first-come queue, copies, transparency log.

Target length. 50 to 60 seconds.

Check question. What does a mirror do with an update that changes an old mapping?

Script:

A username maps to an identity public key. The map is a global, append only log. A ledger copied to everyone. (Screen: a ledger strip: username, identity key.)

To take a name, you sign a claim. It carries an expiry, and the id of your home server. (Screen: a signed claim with an expiry and a home node id.)

Names are first come, first served. That needs consensus, so one node, the PKI node, confirms each claim. (Screen: first come, first served.)

The log is mirrored on every Peergos node. Mirrors reject any update that is not append only. (Screen: the log copied on every node.)

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. (Screen: a key transparency log.)

Idea. 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.

Why it matters. It is what makes "any server" literal.

Context assumed. Units 6 and 15.

Metaphor. A home with a forwarding address; spoken at beat 2.

Misconception. Peergos has a central server for data. Addressed at beat 4; the PKI node of unit 15 is the one global service.

Visual language. Home server with three slots, any-server client, tunnel, two servers, house.

Target length. 45 to 55 seconds.

Check question. What does the server that forwards a write actually see?

Script:

Every user has a home server. It runs an IPFS node, holds your pointers, and keeps the requests other users send you. (Screen: a home server box: IPFS node, pointers, follow requests.)

But you can talk to any Peergos server. Your home has a forwarding address. (Screen: a client talks to any server.)

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. (Screen: the request tunnels through; ciphertext and a signed pointer inside.)

Users on different servers share with each other directly. No central server stores your data or watches it move. (Screen: two users on two servers sharing.)

And a home server can be at home. A small machine, on your own connection. (Screen: a house with a small server inside.)

Idea. 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).

Why it matters. Portability is the difference from federated systems.

Context assumed. Unit 16.

Metaphor. Moving house and keeping your name.

Misconception. Changing servers means a new account and lost contacts. Addressed at beat 4.

Visual language. Username, copy arrow, log update, unchanged friends, mirror.

Target length. 45 to 55 seconds.

Check question. What must your friends do when you move servers?

Script:

Your identity is not tied to any server. The name, the keys, and the files are yours. (Screen: a username not tied to a server.)

To move, you copy your data to a new home server. (Screen: the data copied to a new server.)

Then you update your claim in the log: this is my home now. (Screen: the PKI claim updated with the new home.)

No one you share with has to do anything. Links keep working. Friends stay friends. (Screen: friends unchanged.)

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. (Screen: a second server mirroring.)

Idea. 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.

Why it matters. It is how connections form without a server learning who knows whom.

Context assumed. Units 10 and 16.

Metaphor. An envelope with only the recipient's name on the outside; spoken at beat 1.

Misconception. The server sees who sent a request. Addressed at beat 2.

Visual language. Sealed request, single-use key, recipient's server, capability, deletion.

Target length. 50 to 60 seconds.

Check question. Which way does the capability travel in a follow request?

Script:

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. (Screen: a sealed request addressed to one user.)

It is sent from a fresh, single use key pair. The server cannot see who sent it. (Screen: a fresh single-use key as the sender.)

It waits on the recipient's home server, not in the public store. (Screen: the request waits on the recipient's server.)

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. (Screen: the request carries a capability to a folder; accepting keeps it.)

Once read, the request is deleted from the server. The capability lives on in your own encrypted store. (Screen: the request deleted after it is read.)

Idea. 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.

Why it matters. It is the privacy claim about contacts made concrete.

Context assumed. Unit 18.

Metaphor. A friendship is a folder.

Misconception. The social feed needs a server that knows the graph. Addressed at beat 4; beat 5 states the honest remaining leak.

Visual language. Sealed list, folders per friend, feed, a write into your own space, two friends and an onion.

Target length. 45 to 55 seconds.

Check question. What is a friendship in storage terms, and what is the one access pattern that can still leak?

Script:

Who are your friends? That is data, and it is encrypted like any other data. (Screen: a list of friends, sealed.)

Each friendship is a shared folder. What you share with them goes in it. (Screen: a shared folder per friend.)

Files your friends share with you appear in your newsfeed. That feed is those folders, read together. (Screen: a feed assembled from shared folders.)

A share is a write into your own space. The server sees you write. It does not learn who follows whom. (Screen: ['a share is a write into your own space'].)

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. (Screen: two friends reading one file; a Tor onion, planned.)

Idea. 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.

Why it matters. It states the security claim precisely, including its edge.

Context assumed. Unit 6.

Metaphor. Checking the seal on everything that arrives; spoken at beat 1.

Misconception. "Trust-free" means nothing can go wrong. Addressed at beat 3.

Visual language. Client checks, server crossed, refuse, client source, three users (web over TLS, the downloaded app, built from source).

Target length. 50 to 60 seconds.

Check question. What is the one thing a malicious server can still do to you?

Script:

A Peergos client checks the seal on everything that arrives. The hash of every block. The signature of every signed thing it receives. (Screen: a client checking a hash and a signature.)

So a server cannot alter your data, and cannot forge a pointer. It can only store and serve. (Screen: the server unable to forge or alter.)

What a server can still do is refuse. Availability is the trust that remains. (Screen: what remains: availability.)

The client you run is the last piece. You have to get a real copy of Peergos from somewhere. (Screen: the client itself: where did it come from.)

Three ways to get one. Trust the web and its certificates. Download the app. Or build it yourself. (Screen: three users: web over TLS; the downloaded app; built from source.)

Idea. 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.

Why it matters. It is how third-party code runs on private data without becoming a leak.

Context assumed. Unit 9.

Metaphor. One door and a doorman; spoken at beat 3.

Misconception. Apps can phone home. Addressed at beats 3 and 5, with the book's own caveat.

Visual language. App folder, hostname, service worker, manifest, server.

Target length. 50 to 60 seconds.

Check question. What does an app have access to before you grant anything?

Script:

A Peergos app is a folder of plain HTML and JavaScript, with a manifest. (Screen: an app folder: HTML, JavaScript, a manifest.)

It runs under its own hostname, the hash of its path. Isolated from Peergos and from every other app. (Screen: the app under its own hostname, isolated.)

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. (Screen: requests pass through a service worker to the Peergos tab.)

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. (Screen: the manifest: no permissions by default.)

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. (Screen: the server never sees the app's assets; one gap labelled WebRTC.)

Idea. 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.

Why it matters. It turns the sharing model into publishing.

Context assumed. Unit 21.

Metaphor. A website that is just a folder.

Misconception. Publishing means a public server. Addressed at beat 3.

Visual language. Folder with index, browser, share, no-exfiltration, path link.

Target length. 45 to 55 seconds.

Check question. How do you publish a private website?

Script:

Any folder in Peergos can be a website. Put your pages in it, and it is one. (Screen: a folder with index.html inside.)

It opens in the built in browser, under its own origin, like an app. (Screen: the site viewed in the built-in browser.)

To publish it, you share the folder. Directly, or with a secret link. (Screen: sharing the site like a folder.)

Nothing can leave the page, with the same one gap as apps. Third party tracking is impossible. Fingerprinting learns nothing. (Screen: no exfiltration; tracking impossible.)

Sites link to each other by file path. A private web, with the same locks as your files. (Screen: a link between two private sites by path.)

Idea. 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).

Why it matters. It is the everyday feature that the chunk model makes cheap.

Context assumed. Unit 4.

Metaphor. Two folders kept equal by sending only the differences.

Misconception. A changed file is re-uploaded whole. Addressed at beat 2.

Visual language. Two folders, changed chunk, delete toggles, three devices, merge.

Target length. 45 to 55 seconds.

Check question. A 1 GB file gets one byte changed. What is sent? And what still counts as a conflict?

Script:

Sync keeps a local folder and a Peergos folder the same. Both directions. (Screen: a local folder and a Peergos folder, arrows both ways.)

Change a big file, and only its changed chunks are sent. The rest of the file stays where it is. (Screen: one chunk of a big file changed; only it is sent.)

Deletes can follow in either direction, or neither. You choose. (Screen: delete toggles: local, remote, both.)

Several devices can sync the same folder. A laptop, a desktop, a phone, each holding a copy. (Screen: three devices on one folder.)

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. (Screen: two writes to different files; both land.)

Idea. 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.

Why it matters. Builders need to know how live and how funded the project is.

Context assumed. Unit 1.

Metaphor. A year in numbers.

Misconception. Peergos is a research prototype. Addressed at beat 1.

Visual language. Release count, three features, audit badge, jar, 2026 list.

Target length. 50 to 60 seconds.

Check question. Who audited Peergos in 2024, and what did they find?

Script:

In twenty twenty five Peergos shipped twenty releases. More than double the year before. (Screen: twenty releases in 2025.)

Post quantum sharing. Native apps for Windows, macOS, Linux and Android. Folder sync, and folder loading up to a hundred and fifty times faster. (Screen: post-quantum seal; native apps; sync.)

A second security audit, in twenty twenty four, by Radically Open Security. No high or elevated findings. Two moderate, six low. All fixed. (Screen: audit badge: 0 high, 2 moderate, 6 low, all fixed.)

It is a non profit with no investors, funded by its users. Paying customers tripled in the year. (Screen: non profit; no investors.)

The stated plan for twenty twenty six: polish, usability, iOS, and deeper OS integration. (Screen: 2026: polish, usability, iOS.)