There is a particular kind of unease that comes from using something essential without understanding it. The heating stops. An account is suspended. A familiar tool announces new terms. Nothing in the physical world has changed, but a capability that felt like yours has quietly become conditional.
We cannot remove every condition from our lives. Nor should we want to. A useful life depends on other people, on inherited knowledge, on infrastructure we could never build alone. But we can ask a better question than “Am I independent?” We can ask: where do I still have meaningful choices?
Practical Sovereignty is an exploration of that question. It is about understanding the systems we rely on, acquiring enough competence to work with them, and keeping a few doors open.
Independence is the wrong finish line
Try to follow a single dependency to its end. A home server depends on electricity, a network, replacement parts, software maintainers, and the people who made its processor. Grow your own vegetables and you still inherit seed varieties, weather knowledge, tools, and soil shaped by previous generations.
Total independence is not a useful specification. It gives us no stopping rule and very little help in deciding what to do on Saturday morning. Worse, it can turn a constructive practice into a purity contest. Someone else will always have compiled more of their software or grown more of their lunch.
A more useful aim is deliberate dependence. We choose some relationships because they are valuable. We strengthen others because they are fragile. We retain alternatives where losing a service would cost us more than we can comfortably bear.
This is compatible with enthusiasm for technology, trade, and institutions. The point is to participate with some understanding of the terms.
Intermediate · Write a one-page threat model, not a manifesto
For one capability (mail, git hosting, payments, household records), write four lines:
- Asset — the thing that must remain usable (the mailbox, the remote, the wallet seed, the export).
- Hinge — the dependency whose failure stops the asset (the IdP, the registrar, the phone, the only disk).
- Adversary / accident — be specific: vendor lock-in, disk death, lost phone, account recovery mail going to the same Gmail you are recovering.
- Test — the smallest rehearsal that would falsify “I can continue.”
If you cannot name the hinge, you do not yet have a design. If you cannot name the test, you have a slogan.
Capability makes choice real
An export button is an option. Knowing what the export contains, where to put it, and whether another tool can read it is a capability. The difference often stays invisible until the day we need to leave.
The same distinction exists in physical systems. A set of tools does not make a workshop. A shelf of books does not make the knowledge retrievable. A spare part is only useful if someone can identify the failed component and fit the replacement safely.
Sovereignty without practical capability is mostly theoretical.
Capability does not require mastery of everything. It might mean knowing enough about plumbing to describe a fault clearly to a professional. It might mean being able to restore your documents to another computer. It might mean knowing which neighbour can help, and being useful to them in return.
Often the most valuable competence is the ability to distinguish a task you can attempt from one that needs a qualified person. Recognising a limit is part of understanding a system.
Expert · The trusted computing base is the real inventory
A useful inventory is not “apps I like.” It is the trusted computing base of one activity: firmware, kernel, authenticators, key storage, DNS, certificate authorities, backup media, and the humans who can reset any of those.
Ask, for each layer: can I replace it without the layer above? A password manager that can only be unlocked via the same mailbox it is supposed to protect is not a second factor. A hardware token whose seed was generated by a closed vendor tool, never shown to you, is a token, not a backup. A git remote you cannot git clone after the SaaS account dies is a bookmark.
The expert move is to shrink the TCB on purpose: offline OpenPGP certification keys, authenticators you can re-enrol, backups you have restored onto a machine that never saw the original disk. The discovery essays in this journal are the map. The expert essays are the machinery.
Start with consequences
The word “sovereignty” can invite very large ambitions. Daily life usually improves through smaller decisions. Which account would be hardest to lose? Which piece of household knowledge lives in only one person’s head? Which routine falls apart when the internet is unavailable?
Consider a family photo collection. One household may be well served by a convenient cloud service and an independently readable local copy. Another may prefer a local library with an off-site backup. Neither arrangement is sovereign merely because of where the files sit. What matters is whether the people involved can retrieve them, understand the arrangement, and recover when a component disappears.
The right amount of effort depends on the consequence of failure. An occasional inconvenience does not deserve the same engineering as the only copy of a decade’s work. A system can also be too elaborate for the people maintaining it. Complexity consumes attention, and attention is a finite household resource.
Knowledge should survive its keeper
A surprisingly powerful test is to imagine that the person who built a system is unavailable. Can anyone else find the shut-off valve, renew the domain, locate the important records, or identify the correct backup?
If not, the household may have traded dependence on a company for dependence on an individual. That can be an improvement in some respects, but it is not the end of the work.
Readable documentation, ordinary formats, labelled components, and patient teaching distribute capability. They make the system less mysterious. They also create a more generous form of autonomy: one that other people can participate in rather than merely benefit from.
A practice with no purity test
This publication moves between computing, homes, tools, land, knowledge, and the institutions around them. These subjects share a practical structure. Every system has dependencies. Every choice has maintenance costs. Every escape path needs occasional use to remain real.
We will ask what a tool enables, what it asks in return, and what happens if it stops working. We will treat maintenance as interesting work. We will favour explanations that leave the reader more capable over declarations that leave them more certain.
There is no certificate at the end of this process. You can rent a home, buy food, use cloud services, and still make thoughtful progress. Start with one dependency that matters. Learn its shape. Make one alternative a little more usable.
The aim is not to stand apart from the world. It is to take part in it with your eyes open and your hands available.
