Install something into a system that holds your memories and one question matters more than any other: what is it now allowed to write?

Not what can it read — that's the question everyone asks, and it's the easier one. Write access is how software changes the record of what happened to you.

The old answer, and why it couldn't last

The permission list lived in the core. Each part of the system that accepted writes carried a hardcoded set of what it would admit, compiled in.

That works, and it's genuinely safe, and it has one structural problem: the core has to know in advance about every piece of software that will ever exist. Adding a package means editing the core and shipping a new version of the whole system.

Which quietly decides something much bigger than it appears to. A system whose permission list lives in its own source is a system where the people who ship the core are the only people who can extend it. Every plugin ecosystem that works this way ends up with a gatekeeper, not by policy but by architecture.

The new answer

The package declares its own schema — the kinds of things it writes — and installing it emits that declaration as a governed event on a chain. From then on, the installed schema is what the gate consults.

The write fence no longer reads a constant compiled into the core. It reads the policy attached to the branch being written to. The core stopped being the authority on what may be written, and became the thing that enforces whatever the installed schema says.

That's the whole idea, and it's why the star of this work is phrased as a question about who decides rather than about what is allowed.

Fail closed, and no back-stop

Here's the part I'd defend in review.

When the gate finds no policy at all, it rejects. Not "falls back to the old constant," not "admits and warns." There is deliberately no back-stop.

That's a scarier default than it sounds, because it means a gap in the data becomes a refusal rather than a shrug — so the migration had to be airtight. It was handled by hydrating every registered branch's policy before the daemon begins serving writes at all. By the time any write can reach the gate, the policy is either genuinely there or the branch was genuinely never declared.

So "empty" is unambiguous. It means undeclared, and undeclared means no. And when the gate does hit an empty policy it warns loudly, because a silent drop would be the system lying about having stored something.

A fallback here would have been the comfortable choice, and it would have made the whole exercise pointless: a fence with a back-stop is still governed by the back-stop.

Where the permission applies

An install isn't global. It targets your personal context, or one specific friendship, or one specific hive — and the schema is installed onto that context's chain. The authority exists there and nowhere else.

This is the part most likely to be underrated, so: the ordinary model everywhere else is that installing something grants it standing across your whole account. Here, granting a package the right to write into one shared space says nothing about your personal record or any other space. Permission has a location.

Uninstall means something

The counterpart of a real install is a real uninstall, and this is where most plugin systems get vague — the software goes, and the permissions it was granted quietly persist because nobody wired the removal path.

Here, uninstalling withdraws the authority at the same fence that granted it: the event types that were admitted before are rejected afterwards. The proof of an uninstall isn't that files disappeared, it's that the system refuses writes it used to accept.

What it means for you

Almost none of this is visible while it works, which is the usual fate of permission systems. What you get is narrower than a feature and more durable than one: the answer to what is this thing allowed to write comes from the thing itself, checked at the moment it writes, in the place you installed it.

That has a consequence worth stating plainly. Because authority travels with the package rather than living in a list at the centre, extending this system does not require permission from the people who built it. Someone can write something that runs in your memory without us adding a line to our code first — and without you having to trust that we vetted it, because the fence reads what was actually granted rather than what anyone intended.

A list in the middle is the shape that quietly decides who is allowed to build. Getting rid of it is the whole point.

---

Written by AI agents from real project logs; owned and edited by Mujo.