Essay 01 / Society

[Sovereignty - definition] What Practical Sovereignty Means

Not a life without dependencies. A life where you understand them, can recover when one fails, and can leave when the terms change.

A footpath beside a still alpine lake, surrounded by conifer forests and mountains.
Different paths. A more resilient whole. An original illustrative landscape.

Practical sovereignty is not living without help. It is knowing what you depend on, being able to continue when a piece fails, and having a way out when the terms change.

You will still use bakeries, compilers, and hosted git. The question is whether those relationships are choices you can reverse, or traps you notice too late.

Independence is the wrong finish line

A home server still needs electricity, parts, maintainers, and the people who made the processor. Grow vegetables and you still inherit seed, weather knowledge, and soil you did not invent.

Total independence has no stopping rule. It also turns a useful Saturday into a purity contest: someone else will always have compiled more of their software. A better aim is deliberate dependence. Keep the relationships that are worth it. Put a tested alternative under the ones whose loss you cannot afford.

Intermediate · Write a one-page threat model, not a manifesto

For one capability (mail, git hosting, payments, household records), write four lines:

  1. Asset — the thing that must remain usable (the mailbox, the remote, the wallet seed, the export).
  2. Hinge — the dependency whose failure stops the asset (the IdP, the registrar, the phone, the only disk).
  3. Adversary / accident — be specific: vendor lock-in, disk death, lost phone, account recovery mail going to the same Gmail you are recovering.
  4. 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 a claim. Opening that export in a second tool is a capability. A spare part is only useful if someone can identify the failed component and fit it. A password manager that can only be unlocked via the mailbox it is supposed to protect is not a second factor.

You do not need mastery of everything. You need enough skill to tell a job you can attempt from a job that needs a qualified person. Recognising a limit is part of the work.

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 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

Which account would be hardest to lose? Which household fact lives in only one head? Which routine dies when the network does?

A photo library is not “sovereign” because it sits on a NAS. It is usable if the people involved can retrieve it, understand the arrangement, and recover when a disk or a login disappears. An occasional inconvenience does not deserve the same engineering as the only copy of a decade’s work. A system that is too elaborate for the people who must run it will not be run.

Knowledge should survive its keeper

If the person who built the system is unavailable, can anyone else find the shut-off, renew the domain, or identify the backup?

If not, you traded a company for a single human. Readable notes, ordinary formats, labelled parts, and showing someone else the steps once are how that stops being the design.

A practice with no purity test

This journal moves between computers, houses, tools, and institutions because they share a structure. Every system has dependencies. Every choice has a maintenance cost. Every exit path needs occasional use or it is a rumour.

You can rent a home, buy food, use cloud services, and still make progress. Pick 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.

Next essay →Back to the beginning ↑