Willow is a set of protocols for independent digital spaces that keep working when scaled down and keep deletion and privacy.

Willow is a set of protocols for running your own digital spaces. Small private networks, next to big public ones.

It is built to scale down. A lost signal. A disaster. Two laptops and a cable should still work.

It keeps the things peer to peer systems usually give up. Deletion, most of all.

Others can carry your data without reading it. And you can find people who share your interests without telling the world what they are.

Four parts. A data model. A capability system called Meadowcap. Sync. And drops. This series takes them one idea at a time.

Check yourself. Name two things Willow keeps that peer-to-peer systems usually give up.

Willow addresses data by name, so a name can get new contents or none; the hash is inside the record, not the address.

Many peer to peer systems find data by its hash. Change one byte, and it is a different thing with a different address.

Willow names data instead. Like a shelf label in a library. The label stays. The book on it can change.

Put a new book on the shelf, and the old one is gone. Same name, new contents.

Put an empty book there, and the old one is gone. That is deletion.

The hash is still there, inside the record, to check the contents. But the address is the name.

Check yourself. Where does the hash of the contents live, and what is the address?

A name is a namespace, a subspace, and a path; every entry has all three.

A name in Willow has three parts. Picture a building.

The namespace is the building. Each one is completely independent of every other.

A subspace is a room inside it. In most buildings, each person writes in their own room.

A path is the shelf label inside the room. A sequence of parts, like folders. Blog. Ideas. Game.

Building, room, shelf. Namespace, subspace, path. Every piece of data has all three.

Check yourself. Which of the three coordinates usually belongs to one author?

An entry is the name plus a claimed timestamp, a payload digest and length; the payload is separate and can move later.

The record Willow stores is called an entry. Think of an index card. The name is on it. Namespace, subspace, path.

A timestamp. When the author says it was written.

And a hash of the contents: the payload digest. Plus the payload length.

The contents themselves, the payload, are a separate parcel. Large or small.

So the card can travel without the parcel. Peers can agree on which entries exist before any payload moves.

Check yourself. Can two peers know they hold the same entry without exchanging its payload?

For one subspace and path only one entry survives: later timestamp, then greater digest, then longer payload; the loser is dropped.

Two entries, same room, same shelf. Only one can stay.

The one with the later timestamp wins.

Same timestamp? The greater fingerprint wins. Same fingerprint? The longer payload wins.

The loser is dropped. Not kept in a history. Dropped. Willow calls this destructive editing.

The rule needs no server and no conversation. Any two machines with the same two cards pick the same one.

Check yourself. Two entries have the same timestamp. What decides?

Within one subspace, a newer entry at a prefix removes every older entry with a longer path beneath it, so a folder is deleted in one write, leaving only the new entry.

In one room, a path is a sequence of parts. Blog. Blog, ideas. Blog, drafts. Blog, game.

Write a newer entry at just blog.

Every older entry whose path starts with blog is gone. Ideas, drafts, game. All of them.

This is prefix pruning. A newer entry at a prefix overwrites everything longer beneath it.

That is how you delete a whole folder in one write. No tombstones for each file. One card at blog. Nothing else.

Check yourself. How many writes does it take to delete a folder with a thousand files?

A store is a set of entries under the two rules; joining stores is order-independent; a store holds the present state and no history.

A store is a set of entries from one namespace. Two rules hold inside it: newer wins, and prefixes prune.

To sync, two stores are joined. Pour both sets together. Apply the two rules.

Join them in either order, any number of times. You get the same store.

Mathematicians call that a join semilattice. Programmers call it a state based CRDT.

What it does not keep is history. A store is what is true now. Not how it got there.

Check yourself. Join store A with B, then with B again. What changes the second time?

Timestamps are what the author claims and no one can verify; if only you write in your subspace no other clock can touch it; the dangerous case is future-dating your own writes.

The timestamp on an entry is what the author stamps on it. No one can verify it.

So what can a wrong clock do? If only you write in your room, no one else's clock can touch it.

The real danger is your own clock running fast. A far future entry blocks your later writes under that path, until time catches up.

So peers may refuse entries too far ahead of their own time. And a write ticket, which comes later, can bound the timestamps a writer may claim.

Why not track causality with a vector clock instead? That needs a slot for every concurrent writer, with no bound in a peer to peer system.

Check yourself. Whose data can a wrong clock damage?

A key pair is a public key and a secret key that signs; a communal namespace gives each subspace to its key holder, an owned namespace gives everything to the namespace key, with no list anywhere; Willow'25 decides by the key's lowest bit.

Meadowcap is Willow's permission system. It knows two kinds of building.

In a communal namespace, every room belongs to whoever holds its key. A key pair is a public key anyone can see, and a secret key only you hold. Only the secret key can make a signature the public key checks. The subspace id is a public key. Your signature proves the room is yours.

In an owned namespace, the building itself has a key. Its holder owns every room, and peers reject anything without that signature. There is no list.

Which kind is a given namespace? The id says so. In Willow twenty five, the last bit of the key decides.

Rooms with their own keys, for a club where everyone keeps their own notes. One key over the door, for a group where one party decides who writes.

Check yourself. In a communal namespace, what proves a room is yours?

A Meadowcap capability is an unforgeable ticket naming access mode, namespace, area and holder key, checkable by any peer alone.

Meadowcap has no accounts and no access lists. It has tickets. A capability is an unforgeable ticket.

The ticket says four things. Read or write. Which namespace. Which area. And who holds it.

The area is a room, a shelf prefix, and a time range. Everything inside that is allowed. Nothing outside.

The holder is a public key. To use the ticket, you sign with the matching secret key.

Any peer can check a ticket on its own. There is no server to ask.

Check yourself. What four things does a capability say?

A holder can sign a smaller ticket for another key; each step's area must fit inside the previous; the chain travels with the ticket.

You hold a ticket for a whole room. A friend needs one shelf.

You sign a new ticket for them. Same namespace. A smaller area. Their key as holder.

Their ticket carries the whole chain. The original, and every signature after it.

Each step must fit inside the step before. You can tear a ticket smaller. You can never grow one.

Your friend can pass it on the same way. Smaller again. No one asks you.

Check yourself. Can a delegated ticket cover a shelf the parent did not?

An entry is accepted only with a token: a genuine write capability whose area covers it, and the holder's signature over the entry; three checks.

An entry by itself is just a claim. Anyone could write a card with your room's name on it.

So every entry travels with a token stapled to it. A write ticket whose area covers the entry.

And a signature over the entry, by the ticket's holder.

A peer checks three things. Is the ticket genuine? Does it cover this entry? Did its holder sign it?

A store holds only entries that pass. Willow calls them authorised entries.

Check yourself. What three checks does a peer make before storing an entry?

There is no revocation; a ticket's time range bounds the timestamps it may claim, so short tickets plus renewal plus newer-wins limit a stale writer.

There is no way to cancel a ticket you have issued. Nobody keeps a list to cross it off.

What a ticket has is a time range. It covers entries with timestamps inside that range, and no others.

So issue short ones. Renew the people you still trust.

Someone you stopped renewing can still write within their old range. But your newer entries win over anything they can claim.

The range bounds claimed timestamps, not the wall clock. That is the whole trick.

Check yourself. What does a ticket's time range bound: the wall clock or the claimed timestamp?

An area is one subspace or any, a path prefix (always with everything beneath it), and a time range: a block of the three-dimensional space that tickets grant, sync asks for and queries ask for.

Entries live in three dimensions. Subspace, path, time.

An area picks one room. Or any room. One room means one author. Any room means everyone.

A shelf prefix. Everything under blog. Or only everything under blog, ideas.

And a time range. From here, to there, or open ended.

Say: Betty's room, everything under blog, this year. Three choices. One block.

That block is an area. Tickets grant areas. Sync asks for areas. Queries ask for areas.

Check yourself. What are the three parts of an area?

Peers name areas of interest with count and size limits and sync only the overlap; partial sync is the normal case.

A namespace can be enormous. You rarely want all of it.

So you name an area of interest. An area, plus a limit: at most this many entries, at most this many bytes.

Under a limit, the newest entries win the places.

Two peers each bring their areas of interest. They sync the overlap. Only the overlap.

A phone can follow one shelf of one room. Partial sync is the normal case, not a special one.

Check yourself. Under a count limit, which entries are kept?

Peers compare one fingerprint per region, split regions that differ, and send entries only when a region is small; the fingerprint also counts held payload bytes; bytes sent follow the differences, rounds follow the logarithm of the size.

Two peers share an area. Which entries does one have that the other lacks?

Each side computes one fingerprint over all its entries in the area. Think of a seal over the whole box. Same seal, same contents. Done.

Different? Split the area and compare again.

When a region is small enough, just send its entries.

The fingerprint also counts how much of each payload a peer holds. So a half downloaded parcel shows up as a difference too.

The bytes sent grow with the differences. The rounds grow only with the logarithm of the size. Willow calls this region based set reconciliation.

Check yourself. Two peers hold identical areas. How many entries are sent?

In Confidential Sync, peers exchange salted hashes of their interests and compare them with the other's salt, so only shared interests are detected and nothing new is revealed.

In Confidential Sync, before syncing, two peers must find what they both care about. But naming an interest can give something away.

Say one of your shelves is called gemma stinks. Asking the other peer about it tells them what you think of Gemma.

So neither side names anything. Each scrambles its interests with its own salt, a random string mixed in before hashing. And sends only the scrambles.

Each side rescrambles what it already knows with the other's salt. A match means a shared interest. No match reveals nothing.

Only for matches do they exchange read tickets. Nothing new leaves either side.

Check yourself. What does a peer learn about an interest it does not share?

A handshake binds a key to the session and read tickets must be for that key, so a peer sends nothing outside their areas; a middle box that swaps keys has no ticket for its own key and gets nothing.

Every sync session starts with a handshake. Each side proves it holds its key, and the link is encrypted.

To receive entries, you show a read ticket. Its holder must be the key you just proved. Like a doorman who checks the ticket, and the face it was issued to.

A peer never sends data outside the areas your tickets cover. Not even to say it exists.

A peer can even make a fresh key pair for one session. It delegates itself a ticket for that key, and throws both away after.

A box in the middle can swap keys in the handshake. But then it needs a ticket for its own key, and it has none. It gets no entries and no names.

Check yourself. Why must a read ticket's holder match the handshake key?

Willow's sync protocols require a tree hash (Bab), so each chunk is verified on arrival and a partial payload is a verified partial.

A payload can be large. The entry holds its digest, so you can check it when it arrives.

With an ordinary hash, you check only at the end. A bad peer could send gigabytes of garbage first.

Willow's sync protocols require a tree hash, called Bab. The payload is cut into chunks, and the digest covers the tree.

Each chunk is checked as it arrives, against the digest you already hold. Bad data is caught early, not at the end.

A half received payload is a verified half. You can pass it on, or stop, and lose nothing.

Check yourself. At which chunk is garbage detected?

You seal payloads, paths are sealed one part at a time so prefixes survive, timestamps and ids stay plain, and relays can merge what they cannot read. Post note: capability tokens travel in the clear too.

You can let a server carry your data without reading it.

You encrypt the payload. The server sees a parcel it cannot open.

The path is encrypted one part at a time. Blog, ideas, game become three scrambled parts.

Two paths that share a prefix still share it after scrambling. So prefix pruning and areas keep working on data nobody can read.

Timestamps stay plain, because newer wins has to compare them. The ids stay plain too. The server can relay and merge, and never learn what any of it says.

Check yourself. Why are timestamps left unencrypted?

A drop is one file of entries, tokens and payload slices that any channel can carry; payloads may be missing; the receiver verifies and joins it like any store.

Sync needs a live connection. A drop does not.

A drop is one file. Entries, their write tokens, and slices of payloads.

A payload can be missing or partial. The entry still arrives, and the digest says what to fetch later.

The receiver checks every token and joins the drop into their store. The same two rules as always.

Any channel will do: a stick, a message, the post. Encrypt the drop first.

Check yourself. What must the receiver check before joining a drop?

The data model leaves the hash and Meadowcap leaves the signatures as parameters; Willow'25 fixes them (Ed25519, WILLIAM3, 4096, ChaCha20-Poly1305, a Noise-style XX handshake the authors call Nose) so implementations interoperate; not a new protocol, and no new set until a primitive breaks.

The data model does not say which hash to use. Meadowcap does not say which signatures. Those are parameters. Each app could choose its own.

Willow twenty five fills the slots. Not a new protocol. The same protocol with its blanks filled in. Ed25519 keys and signatures. WILLIAM3 hashes, from the Bab tree hash.

Path limits: four thousand ninety six parts, four thousand ninety six bytes each, four thousand ninety six bytes in all.

ChaCha twenty Poly thirteen oh five for encryption. A Noise style XX handshake, with those same primitives. The authors call it Nose.

One set, so that implementations interoperate. The authors intend no new set until one of these primitives is broken.

Check yourself. Which hash function does Willow'25 use, and where is it defined?

willow://namespace.subspace/path names an entry (the words stand in for keys); a digest pins a payload; ?area with limits names an area; a hint is only where to look first.

A Willow URI starts with willow colon slash slash. Then the namespace, a dot, the subspace, and the path. Family and alfie stand in for keys.

Add a digest, and it names one exact payload.

Add the word area, and it names everything under that shelf.

An area URI can carry a count, a size, and a time range. The same limits sync uses.

It can also carry a hint: a place to look first. The name is the address. The hint is directions.

Check yourself. What does adding ?area to a URI change?

The data model and Meadowcap are final; the drop format and Willow'25 are proposals on their pages (the changelog calls drops a candidate); Confidential Sync, home of the private overlap detection, is paused; the Willow Transfer Protocol, dated October 2026, is the live proposal and sends requests and tickets in the clear.

Which parts can you build on today? The site stamps every spec with a status.

The data model and Meadowcap are final. Meadowcap became final in twenty twenty five.

The drop format and Willow twenty five are still proposals.

Confidential sync, the private protocol of the earlier units, is paused. A simpler Willow transfer protocol is the live proposal, dated October twenty twenty six. It sends requests and tickets in the clear.

So the model and the tickets are settled. How peers talk, and how privately, is still being decided.

Check yourself. Which two specifications are final?