Who may access a document must be a pure function of a set of signed certificates, so every replica computes the same answer, in any order, with no referee.

In local-first software, every device holds the whole document. Edits merge whenever devices meet. So who is allowed to edit?

With a server, that is a table, and the server decides. Here there is no server. Each device has to decide alone.

And they all have to agree. If your laptop says Carol may edit, and your phone says no, one device keeps her edits and the other throws them away.

Keyline never stores the answer. It computes it, every time, from a bag of signed notes. The notes are called certificates.

There are two kinds. A delegation: Alice says Bob may edit this document. A revocation: Alice takes that note back, naming it by its hash.

Notes are only ever added. Nobody edits one. Nobody deletes one. Merging two bags is pouring them together.

The answer depends only on which notes are in the bag. Never on the order they arrived. Same bag, same answer, on every device.

That is the whole constraint. No clocks. No order. No referee. Just the bag.

Check yourself. Why can Keyline not store "Carol may edit" as a fact that gets updated?

A delegation is not a proof you carry. You hold authority only while an unbroken chain of live delegations runs from the subject to you, and the verifier finds that chain by searching the whole set.

In most systems, a credential is a ticket. You show it at the door, and the door checks the ticket itself. The ticket carries its own proof.

A Keyline delegation carries no proof. It says who signed it, who it is for, what it is about, and how much power. That is all.

So how is it checked? Picture the document as a wall socket. Each delegation is a power strip, plugged into another strip.

You have power if current reaches you. It flows out of the socket, through every strip, to your device. Not because your strip says so. Because current arrives.

Bob can plug Carol in before Bob has any power. Her cord just sits there, dark. The moment someone plugs Bob in, Carol lights up. Nothing is re-signed.

Unplug Bob, and Carol goes dark. Her certificate did not change. It is not revoked. It is dead. No current reaches it.

Plug Bob back in, and Carol returns. Same certificate. Same signature.

Junk is harmless. A ring of strips with no path to the wall carries nothing. Anyone can sign anything. Only routes matter.

A certificate is never valid or invalid on its own. It is live or dead, in the context of the whole bag.

Check yourself. Bob signs a delegation to Carol while Bob himself has no access. What happens when Bob is later given access?

Your power over a subject is the maximum over routes of the minimum power along each route. Levels clamp, they never reject.

Power comes in four levels. Relay, read, edit, admin. Relay carries content it cannot read. Admin can act on the wiring itself.

Every strip has a breaker, set to its level. You never draw more than the weakest breaker on your chain.

Alice has edit. She writes admin on Carol's certificate. Not an error. Carol gets edit.

Why not reject it? Alice might be given admin tomorrow. Then Carol's certificate, unchanged, carries admin. A certificate states a ceiling, not a fact.

Two chains? Carol is plugged in through Alice at edit, and through Dan at read. She gets the better one. Edit.

Minimum along a route. Maximum across routes.

The second chain is insurance. If Alice's chain breaks, Carol still has read through Dan. There is never one brittle proof to lose.

Check yourself. Alice holds Read and delegates Admin to Carol. Dan holds Edit and delegates Edit to Carol. What is Carol's power?

A subject bootstraps its own authority by signing exactly one certificate to a root role and then destroying its signing key, so its identity is permanent and its authority lives elsewhere.

Everything in Keyline is a public key. People, devices, groups, documents. The graph does not know which is which.

So a document has a key, and a key can sign. Where does the first wire come from? The document signs it itself.

At creation, the document's key signs one delegation, to a fresh key called Owners. Owners' key signs the creator in. Then both private keys are destroyed.

The document's public key is its identity. That is permanent. Its authority now lives somewhere else. In Owners.

Why destroy the keys? Whoever held the document's key could rewire the socket. Destroying it makes that first edge the one thing nobody can replace.

That is a trade. Everything below the root can be rebuilt. The root itself cannot.

And the creator is just the first member of Owners. Nothing about their key is special.

Check yourself. Who can sign a second root edge for a document?

A certificate's subject is a scope. About a document, it helps you reach that document and nothing else. About a role, it is membership, and it carries whatever the role reaches, now and later.

Ten people. Fifty documents. One certificate per person per document is five hundred. Every new hire is fifty more.

Keyline has no group object. A role is just another key. Mint it, have it sign Dan in as admin, and throw the private key away.

Two kinds of certificate hang off a role. A supply: Dan gives Members edit over the document. A membership: Dan puts Alice in Members.

Alice's power over the document is the smaller of two things. What Members has over the document. And what Alice has in Members.

A certificate about the document helps you reach that document. Nothing else. A certificate about Members is a membership. It carries everything Members reaches. Now, or in the future.

New document? One supply. Every member has it at once. Nobody re-issues anything.

Someone leaves? Take back one membership. They are out of all fifty.

A membership is a promise about the future. Whatever Members is wired into later, every member reaches it. Each at their own level.

Check yourself. Members is supplied into a new document tomorrow. What has to be re-issued for Alice to use it?

A revocation names one delegation by hash and deletes nothing. Everything that depended on it dies implicitly, because liveness is recomputed from the whole set.

A revocation says: I take back that certificate. It names one delegation, by its hash. Not a person. Not a key.

Nothing is deleted. The delegation stays in the bag forever. The revocation sits beside it.

Dan takes back Alice's membership. One certificate named. But Carol's membership was issued by Alice. Unplug Alice, and Carol goes dark.

Carol's certificate was not revoked. Nobody named it. It is dead. There is no route to it. That is the cascade.

Why not list everything the revocation cancels? Because Dan's device may not have seen Carol's certificate yet. Two devices would write two different lists.

So a revocation names one thing. One hash. One signature. The same meaning everywhere.

If Carol had a second route, through Dan, that route is untouched. Carol keeps her access.

A revocation unplugs one cord. Whatever goes dark, goes dark because of the wiring. Not because it was named.

Check yourself. Dan revokes Alice's membership. Is Carol's certificate revoked, dead, or live?

Every well-signed revocation is accepted. Its effect is scoped to where its signer stands: their own hop, their own signatures, or any route through a node they hold admin over. The set of nodes you hold admin over, plus your own node, is your admin reach.

Any well-signed revocation goes into the bag. The question is never whether it is valid. The question is what it covers.

First: your own strip. Carol invited Eve. Carol can unplug Eve from her own strip. That cuts routes through Carol, and nothing else.

Second: your own signatures. If you signed a certificate, as giver or receiver, you can kill it on every route. When your key leaks, you can cut everything that names it. No one to ask.

Third: admin. Admin over a node is a key to that room. You can unplug any cord that runs through your room, however far downstream.

Your rooms, plus your own strip, are your reach. Admin in Owners, and Owners is admin over Members? Then you have a key to Members too.

What you cannot do: cut the cord you stand on. The supply that feeds Members runs through rooms above you. Your revocation of it does nothing.

A revocation that touches none of your rooms, and none of your signatures, is a no-op. Not an error. Just inert.

Admin is not a rank. It is a set of rooms. Your revocation power is exactly the cords that run through them.

Check yourself. Bob is an admin of Members. Can he revoke Dan's supply of the document into Members?

Admin reach is computed as if no revocation existed, so it only ever grows. That is what lets two concurrent revocations land the same way on every replica.

Your reach is every room you have ever held a key to. Ever. Not currently. Here is why.

Two revocations at the same moment. Dan removes Bob from Members. Bob, still an admin as far as he knows, removes Eve.

Suppose Bob's reach depended on being an admin right now. A device that sees Dan's note first ignores Bob's. Eve stays. A device that sees Bob's note first removes Eve. Same bag. Different answers.

So Keyline works in two passes. Pass one ignores every revocation and draws the full map. Who ever stood where. That fixes everyone's reach.

Pass two applies all the revocations to that map. Revocations never look at each other. Both land. Everywhere. In any order.

Removing a moderator does not un-ban the people they banned. Quitting does not un-ban anyone either. And two devices never disagree.

Reach only grows. And more reach only ever removes access. The surprise, if any, is always in the safe direction.

The price: a removed admin keeps the keys to every room they ever had. That is the sharp edge.

Check yourself. Why can a replica not shrink Bob's reach after Dan removes him?

No later message can undo an applied revocation, and re-issuing the identical certificate produces the identical, already-revoked hash. So a repair is a fresh grant that cites the revocation, which makes the heal a new, accountable certificate.

Once a revocation is applied, nothing can undo it. A revocation can name a delegation. It cannot name another revocation. There is no undo to write.

So how do you fix a mistake? You grant again. You run a new cord. The old revocation stays in the bag forever.

One wrinkle. Certificates are named by their hash. Re-issue the identical delegation, and you get the identical certificate. Already revoked.

So the new grant carries a tag: the hash of the revocation it is healing past. Different bytes. Fresh hash. And it says, on the record: re-granted, knowing of the removal.

The tag means nothing to the evaluator. It is not an undo. It only changes the hash. A wrong tag is harmless.

Why not random bytes? Then two accidental copies of a grant would be two live certificates. Revoke one, and the other stays. That fails open. With the tag, copies collapse into one, and one revocation covers them all.

Every return of access is a fresh signature from someone with live authority. Never a message arriving in a lucky order.

Check yourself. Dan re-signs Alice's membership byte for byte. Does Alice regain access?

Re-adding a key revives every certificate it ever issued, with the same hashes and provenance. That is a one-certificate repair and a hazard, so a removal after key compromise must come back with a fresh key.

When Dan removed Alice, Carol went dark. Carol's certificate is dead. Not revoked. Now the difference matters.

Dan re-adds Alice. Her strip is plugged back in. Carol lights up. And so does everything else Alice ever wired. Same certificates. Same hashes.

As a repair, that is wonderful. Remove by mistake, re-add, and the whole subtree returns for one certificate. Everyone except Eve? One re-add, one revocation.

As a hazard, it is the same thing. Re-add a key, and you revive certificates everyone forgot. Including ones a thief signed while they held that key.

So, after a compromise, re-add the person with a fresh key. The old key never returns. Its certificates stay dead forever.

And when a removal must survive any future re-add, revoke what they issued, not just their membership. Explicit revocations are permanent.

Three kinds of removal. Implicit: reversible. It revives on re-add. Explicit: durable. What you keep must be re-issued. Fresh key: the old key simply never comes back.

Dead and revoked are different states. The difference is one question. Will it come back?

Check yourself. Alice's key was stolen and she was removed. Later "Alice" is re-added with the same key. What happens?

A removed admin keeps their frozen reach forever and can still sign revocations that cover it, so durable removal of an admin requires rotating the role to a fresh key.

Bob was an admin of Members. Dan removes him. Bob cannot read, write, or grant anything. But Members is on his keyring. And keyrings never shrink.

So Bob can keep signing revocations that cut through Members. Against members added years later. There is no clock. His old notes and his new notes look the same.

He cannot take anything. Every note is signed. This is griefing, not theft. But it is forever. Unless you move.

Rotation. Mint a fresh role. Members prime. Its key signs the surviving admins in, and is destroyed. Dan wires the document into Members prime, and unplugs the old supply.

Then the members who stay get re-added. One certificate each. The roster is the whole job.

Everything below comes back by itself. A team Alice wired up from Members keeps working. Nothing re-signed.

Bob's keys now open a room that routes nothing. His revocations stop biting. Even the good ones. The survivors re-sign those.

The survivors' keyrings grow to include Members prime. Their old revocations keep working.

One hazard. The old room is dormant, not demolished. Its roster is still wired inside. Wire a document into old Members again, and every former member lights up. And Bob's keys work again.

After removing an admin, rotate the role. Otherwise the removal is not durable.

Check yourself. Dan revokes Bob's admin membership and does nothing else. Can Bob still cut new members?

A document cannot rotate. Admin over it puts the document itself in someone's reach forever, and admin over a document buys nothing else. So root the document at Edit and supply roles at Edit, unless the owners are the document.

Rotation works because a fresh node comes after the ex-admin. No fact will ever put it on his keyring.

But one node can never be fresh. The document itself. It is the socket in the wall.

Can the socket be on anyone's keyring? Only if someone holds admin over the document. That is set by the root edge's level, chosen once at creation, and by each supply's level.

Root the document at admin, and every admin of Owners, ever, has the socket on their keyring. Rotate all you like. Each of them can unplug every cord in the socket's room. One revocation kills the document.

What does admin over a document buy? Reading, writing, inviting, managing a role. None of it needs admin over the document. Admin over a document is only the power to destroy it.

So root at edit. Supply roles at edit. Then the socket is on nobody's keyring, and rotation always escapes. Root at admin only when the owners are the document, and ending it is the point.

The level is fixed at creation, and anyone holding the bag can see it. It is a fact about the document, not a policy.

Check yourself. A document is rooted at Admin. Members is supplied at Edit, Bob is removed from Members and Members is rotated. Can Bob still revoke the root edge?

Only Admin-level memberships add to anyone's reach. Giving an upstream role Admin over a child role puts the child on every upstream admin's keyring forever, so nest only when seniors should act inside the child; otherwise control a role through its supply, and hold people as members at a level.

Reach comes from one thing: holding admin over a node. Read and edit memberships add nothing to anyone's keyring.

So inviting a thousand editors adds nobody who can cut you off. An editor can still invite others, at or below their own level. Those invitations ride the editor's own strip, and die with it.

Now a choice. Wire Moderators in as an admin of Team X. Then everyone who was ever a Moderators admin holds a key to Team X. Forever. Rotating Moderators does not take it back.

Or keep Team X flat. Its admins are named people. Moderators holds only the cord that feeds it. Control from above is total but coarse: unplug the supply, wire a successor.

Nest when seniors should be able to act inside the junior role. Keep it flat when the role should be governed only as a whole. Nesting is permanent. Supply control is not.

One shape makes this hold. People are members of roles, at a level. The only certificates about a document itself are supplies. Then an ex-admin's reach is exactly the rosters they sat on.

Give admin only over things that can be rotated. And give it to people, not to roles.

Check yourself. Moderators is given Admin over Team X. Later Moderators is rotated. Do its former admins still have Team X on their keyrings?

Removal from the root role is never durable, because only the destroyed subject key could sign a new root edge. So the root role is kept minimal and used rarely, like a root certificate authority.

Every role can rotate, except one. Rotating Owners needs a new root edge. Only the document's key could sign it, and that key was destroyed.

So everyone who ever held admin in Owners keeps Owners on their keyring. And every route in the document passes through Owners. Removal from the root role is never durable.

Rooting at edit keeps the root edge itself off every keyring. But an ex-owner can still unplug the owners' memberships, inside Owners. Then the document goes dark.

Two owners can revoke each other at the same time. Both land. Below the root, whoever feeds the role rotates it and picks who stays. In the root role, there is no one above. If all the owners unplug each other, nobody can ever be added again.

So keep the root role tiny. One key per human owner, or just the creator. Do all the churn in roles below, where rotation works.

One escape hatch. If the document's key was kept, in cold storage, it can cut the old root edge and wire a fresh Owners. That only helps when the document is rooted at edit.

And whoever holds that key can re-root out from under you, too. Destroy it, or guard it.

Check yourself. Why can the Owners role not be rotated?

X can deny Y's access iff every live route from the subject to Y transits X's admin reach. So availability is a min-cut over roles, and the power is deny-only and attributable.

Reach is where you hold keys, plus your own strip. A revocation unplugs cords in your rooms. So when can X cut off Y?

Exactly when every live route to Y passes through a room X holds a key to. Or through X's own strip. Not more. Not less.

A second route protects you only if it runs through different rooms. Two cords through the same role are one cord.

Who holds keys? Admins. Only admins. The one exception is your inviter: if your only route runs through their strip, they can unplug you from it.

And it is bounded. They can never read, write, or escalate. Every revocation is signed, so a spree is a confession. Nothing is taken from you. You keep your copy, and everything you already decrypted.

Rooms near the socket sit on more routes. But fewer people ever held keys to them. The root can cut everything. That is just ownership.

Any system where removal is durable hands every remover this power. Keyline chose durable, then shrank the surface: reach, rotation, flat roles.

Check yourself. Carol has two routes to the document, both through Members. Does the second route protect her from an ex-admin of Members?

A replica can never prove it holds every revocation. But merging is union and revocations are permanent, so withholding one can only delay it, and a single honest peer repairs the omission.

No certificate can be judged alone. Only against a bag. And your bag might be missing something.

Miss a revocation, and you keep honouring access the full set has revoked. Until you sync. That is the window.

Can a dishonest peer keep you in that window forever? No. The moment any peer shows you the red note, it applies. And nothing can ever undo it.

One honest peer is enough. A withholder can delay. Never prevent.

The other direction exists too. If you never saw the note that made K an admin, you treat K's revocations as inert. Short on delegations means short on revocations. As notes arrive, coverage only grows.

Nobody can prove their bag is complete. Absence cannot be witnessed. What you get is weaker, and enough. You can be late. You can never be wrong in the open direction for good.

Check yourself. A peer hides a revocation from you. What bounds the damage?