It's been a while since my last update on Earthstar and Willow. Sorry. It's not been for lack of progress: Aljoscha and I have been working hard on specifications, on the TypeScript implementation of Willow, and on an exciting addition to this family of protocols.

Capabilities

Centralised systems have it easy when it comes to authority. Granting access to a server's data is like a bouncer outside a nightclub: they check their list and let you in (or not) depending what the list says.

It can work this way because all the action (data) is one place: the nightclub.

But in decentralised systems, there's no one nightclub everyone goes to. Instead, everyone is running their own weird little nightclub for themselves.

So if there's no club, and no bouncer, how can you tell what's allowed or not? If Alfie comes up to you and claims he's definitely allowed to view the super secret snacks menu, how do we know he's authorised to do that?

We can replace the bouncer and his fancy list with special permission tickets anyone can verify. These tickets say who is allowed to do what and where, and importantly from whom they got that permission.

These tickets are capabilities, and capability systems have been around for a long time. And now we have have one made especially for the Willow protocol.

Intermission

Earthstar has gotten by with a pretty blunt permission model up to this point.

If you knew a share's public key, you had irrevocable read access. Access which you could give to anyone else.

If you knew a share's private key, you had irrevocable write access. Which you could pass to anyone, who could pass it on to someone else, who could pass it someone else, ad infinitum.

This made the leaking of a share's public and private key a daunting and somewhat inevitable prospect. I would very much like to put this model behind us, and now we finally can.

Meadowcap is a new capability system built especially for Willow (which Earthstar will soon use).

In Willow, a namespace is a self-contained data space with three dimensions: time, path, and subspace (an generalised dimension which replaces Earthstar's author dimension).A namespace's individual entries belong to points within this three dimensional space. These namespaces are very much like Earthstar’s shares.

Meadowcap enforces boundaries on who gets to read and write what data, and grants access to specific areas of the namespace, e.g. a certain span of time, or an area where all discussion board data is stored.

It does this with the aforementioned capabilities, unforgeable tokens bestowing read or write access to some data to a particular person, issued by the owner of that data.

There are four kinds of capability:

• Source: a capability from which all authority over a namespace (or subspace — see below) stems.
• Delegation: a capability which delegates authority over an existing capability to someone else using a cryptographic signature.
• Restriction: a capability which restricts the granted area of an existing capability by intersecting it with another area.
• Merge: a capability which combines many existing capabilities into one.

For example, I might create a new namespace keypair, use it to make a read access source capability, restrict that capability to just my blog, and delegate it to you.

Meadowcap also distinguishes between two kinds of namespace:

• Communal namespaces, where authority is derived from ownership of a given subspace key pair. This is a horizontal model where all members of a namespace have equal authority, and no-one has authority to all data in the namespace. Anyone can participate in a communal namespace by generating a subspace key pair for themselves.
• Owned namespaces, where authority is derived from the ownership a given namespace keypair. This is a top-down model where the owner of the namespace key pair has total control over all data in the namespace, including data written by those who have had capabilities delegated to them. Participation in an owned namespace is completely reliant on being granted capabilities by the owner.

With these different kinds of namespaces and capabilities, we hope it'll be possible to model many different kinds of online spaces, very much tailored to what their users want. Big public spaces with lots of people you don't know, and small private spaces for families, friends, and workgroups.

On the note of adaptability, like Willow, Meadowcap does not prescribe the cryptographic primitives you use: you can use whichever signature schemes and hashing functions you like.

Long story short, this capability system will be a part of Earthstar 11 (that's eleven), and will be specified alongside the Willow protocol. I've just finished the first version of a reference implementation, and will be integrating it with willow-js next.

More news soon. There won't be so long a wait until next time.