An ideology is not a mood. It is a set of things you know how to do.
Learning one changes what a single person can do in a room. Not what they believe — what they can execute. The vocabulary below is not slogans; each one is a practice with a shape, a cost and a competence you either have or don’t.
One command can change your day. It cannot change a neighbourhood, and pretending otherwise is how good practices get mistaken for a politics.
Nobody sensible claims that no decision ever needs elevated permission. Somebody has to hold the keys to the hall. Somebody has to sign for the delivery. Somebody has to speak for the group at the table for two hours on Thursday.
The objective was never to hand somebody permanent root. It is to notice that sudo is a wrapper with four properties — it is specific, it is logged, it expires, and it can be taken back — and that those four properties are the entire difference between a delegate and a ruler.
A mandate without an expiry is not a mandate. It is an office.
Knowing commands changes what one person can do. Combining them changes what a group can do. Tap to build a pipeline and watch the unit of action change underneath it.
This is not a metaphor that was invented for the occasion. It is the oldest working idea in systems engineering, and it has a date.
In 1964 Doug McIlroy wrote a memo at Bell Labs: we should have some ways of connecting programs like garden hose — screw in another segment when it becomes necessary to massage data in another way. The infrastructure did not exist. It sat for nine years. In 1973 Ken Thompson said he was going to do it, and added the pipe to the shell in a single night. McIlroy’s account of the next morning is the part worth keeping: an unforgettable orgy of one-liners as everybody joined in the excitement of plumbing.
Five years later McIlroy wrote down why it worked, and accidentally wrote down the politics too:
Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. M. D. McIlroy · Bell System Technical Journal, 1978
A universal interface. Not a universal program.
The shape generalises, which is the test of whether a pattern is real. Same structure, four different rooms:
In none of them does the first stage own the last. The grower does not employ the kitchen. The translator does not answer to the author. Loose coupling, stronger together — and every stage can be swapped, improved or replaced without permission from the others.
You don’t need to own what comes before or after you. You just need to do your part, and pass it on.
That is the whole property, and it has a corollary worth stating flatly: cooperation composes; control fragilises.
Here the problem changes shape. Repeated practices become routines; routines become institutions; and institutions that intend to stay autonomous need a way to deal with each other that does not involve one of them absorbing the other.
A commune does not need to become a union. A union does not need to become a cooperative. A cooperative does not need to become a second, larger cooperative. What they need is an interface.
So write the practices down the way you would document a program — inputs, outputs, required permissions, and the specific way it fails. Tap any card.
Notice what the failure column does. A practice that cannot name its own failure mode is not documented, it is advertised — and the most common way federations die is that nobody wrote down how this part breaks.
These are not rules handed down. They are shared practices for working together as equals, written to be adapted to different places, needs and scales — and written in a format that lets you check whether the group you are in is actually running them.
Tools for cooperation. Not control.
What passes between two autonomous groups is not a merger. It is a handshake — a short, boring, inspectable exchange after which both parties still exist.
Not assimilation. Not control. A relationship between equals.
Five steps, and only the fifth is ongoing: propose terms, negotiate openly, share what you can, share in return, then keep talking. Nothing in that sequence requires either party to dissolve.
Make it concrete. Two real-shaped communities, each a record you could actually publish:
An urban farming collective of 250 in Cascadia; a rural mutual aid network of 180 in Appalachia. What each offers is what the other requests, which is the entire basis of the connection — and "autonomy": true stays set on both sides after the handshake completes.
Five properties keep it a relationship rather than an acquisition. No ownership — relationships, not control. Mutual benefit — exchange, not extraction. Ongoing, not once — it adapts. Transparent — open terms, open process. And revocable — either side can end or change the agreement at any time, which is what stops it hardening into an institution.
Not one united power, but a web of free associations.
Networks scale because different machines implement common protocols without becoming the same machine. A federation works the same way, and the phrase for what it achieves is worth being precise about: coordination without absorption. Or, as the sheet puts it — the art of staying different while building together.
Centralised systems solve complexity by escalating privileges. Each hard case gets referred upward, each referral becomes a precedent, and eventually everything that matters requires root.
Federation asks the engineering question instead of the moral one. Not who deserves to hold this power — but why is this a privileged operation in the first place? Tap an operation to see it redesigned.
Push authority downward. Reduce the number of privileged operations. Make each delegation specific. Make permissions visible. Make elevation temporary. Make revocation ordinary — not a crisis, not a coup, just a scheduled thing that happens.
And notice that the fix is not a better superuser. It is a different verb. Stop asking for root and start granting capability to the people already standing in the room:
A system that requires root for basic human needs is not a feature. It’s a bug.
Not one superuser. Many capable users. Six properties do the work:
Local control
Decide locally, act autonomously.
Least privilege
Only the permissions needed.
Transparency
Visible, accountable decisions.
Revocability
Permissions can be changed.
Composability
Combine capabilities to do more.
Resilience
No single point of failure.
Give people the tools, not just the keys. A freer world runs on permission — not permission denied.
Do that and federation stops reading as a philosophical abstraction. It starts reading as systems engineering. Power is easier to take than to share, which is exactly why it has to be built for on purpose.
The disagreement is not organisation against chaos. Both of these are organisation. They differ in what grows when you add a participant.
Add a node to the first and you have added something to administer. Add a node to the second and you have added capacity. The unit of scalability is not obedience. It is interoperability.
It’s not a question of chaos or control. It’s a question of architecture.
The same population, arranged two ways, produces two different sets of properties. Not two different moralities — two different failure surfaces.
A system built on authority requires constant trust, and has to keep manufacturing it. A system built on cooperation scales because the people in it do. Scale authority and you get empires. Scale coordination and you get possibilities.
Which makes the last line the important one: a kinder, freer tomorrow is not a mood, a prediction or a hope. It is a design choice.
Any architecture that only publishes its best case is marketing. Here is how this one breaks, and what the design answer is in each case. If you have been in a collective for more than a year you have met at least three of these.
None of these are solved by wanting federation more sincerely. They are solved by rotation schedules, published minutes, sunset clauses, redundant capacity, and a written procedure for recall that somebody has actually used at least once without the group collapsing.
Real problems. Better tools. A more resilient tomorrow.
Once independent groups can talk through shared protocols, those federations can talk to other federations. The same move repeats at every level, which is the definition of a protocol that works.
And this is the part that is not wishful. Elinor Ostrom won a Nobel for documenting how real commons are actually governed over long periods, and the eighth of her design principles is nested enterprises — appropriation, provision, monitoring, enforcement, conflict resolution and governance organised in multiple layers rather than one. Her other principles read like a checklist for this page: those affected participate in modifying the rules, monitoring is mutual, sanctions are graduated, conflict resolution is cheap and local.
That is not a manifesto. It is fieldwork on irrigation systems, forests and fisheries that outlasted the states around them.
Not one process owning every other process. Processes talking to processes. Not permanent root — permissions. Not command and control.
None of the above requires a corporation, a government or a budget.
It requires people who care, a few ordinary tools, and a willingness to write down how you have agreed to work. Seven steps, in the order they actually happen:
Gather people
- Start with a few committed people, not a mailing list
- Say out loud what you share
- Be inclusive and open from the first meeting, because it is far harder to add later
Choose a focus
- Identify a real need in your area — not a cause, a need
- Start small
- Build on what already exists rather than founding a rival
Set up your tools
- A chat space you control — Matrix, IRC, or another federated platform
- A shared document space — Nextcloud, Etherpad
- Keep ownership of both inside the community; a group that rents its own memory has a permissions problem it has not noticed
Agree on principles
- Write a short statement of shared values
- Keep it simple enough that a new person can read it in one sitting
- Revisit it on a schedule, and change it together
Take action
- Run a project or an event — something with a date
- Share resources
- Support each other, and learn as you go
Connect
- Announce that you exist
- Link with other communities, and publish what you offer and what you need
- Share knowledge and tools — stay autonomous, but collaborative
Keep going
- Rotate roles, on a schedule, before anyone becomes load-bearing
- Welcome new people properly
- Celebrate progress, and adapt to new needs
Step six is the one this whole file has been about. Everything before it a good group can do alone. Step six is where a good group stops being an island, and the only thing it requires is that both sides have written down what they offer, what they need, and that they intend to stay themselves.
You don’t need permission to build a better world. You just need people.
A small group of committed people can change a neighbourhood. Many small groups, federated, can change rather more than that — and the difference between those two sentences is not enthusiasm. It is a protocol.
Ten ready-to-post lines from the page above. Every one carries the link back here.
Or share a graphic — each one has its own page and its own social card, so pasting the link renders that image rather than this one.
