From replaceable services to resilient networks: digital sovereignty without miracle cures.
The problem isn’t choosing the right provider
In the first part, we arrived at a rather uncomfortable conclusion: we can build extraordinarily reliable infrastructure and still depend on a single intermediary’s decision.
Our service is replicated, monitored, protected. Then we lose control of the domain, our users’ identities, or the channel through which we receive payments. The servers keep running, but for the people who need to use it, the service has become unusable.
At that point, it’s tempting to ask: which provider would never do this to us?
I’m afraid that’s the wrong question.
No contract, data centre, or Linux distribution can eliminate every risk. What we can do is design systems in which losing one dependency doesn’t mean losing everything. The key isn’t isolation. It’s replaceability.
So let’s return to the four questions that closed the first article. Can I export my data, change providers, control my keys, and keep operating if a service is revoked?
If we can’t answer those questions, we don’t need yet another platform. We need a plan.
Digital sovereignty: fewer slogans, more tested exit plans
Digital sovereignty risks becoming one of those phrases that sound excellent at conferences and rather less convincing in runbooks.
For me, it means something quite concrete: knowing what we actually own, whom we depend on, and what changing course would cost us. Owning the application code isn’t enough if the database can’t be exported or users can only authenticate through an external service. Having a backup isn’t enough if we’ve never tested restoring it onto different infrastructure.
Nor must we necessarily run everything ourselves. A cloud service can be a sensible choice, including from a security perspective, when it lets us focus on the product. But it should be a conscious choice: a provider we can replace is not the same as one we cannot leave.
The serious test, therefore, isn’t asking a salesperson how resilient the platform is. It’s simulating a migration, testing data exports, recovering credentials and keys, and measuring the time and cost of leaving. Ideally, before leaving becomes unavoidable.
Freedom isn’t a checkbox in a requirements document. It’s a property that needs testing.
The tools exist. But each solves a different problem
Let’s look at our digital lives as layers of decisions rather than one product we have to buy.
On the device, GNU/Linux gives us the ability to understand, modify, and replace important parts of our working environment. On mobile, GrapheneOS takes an approach focused on hardening and reducing the attack surface, on compatible hardware. That doesn’t mean every Linux configuration is automatically more secure than every alternative, or that changing operating systems is enough to make us invisible.
At the infrastructure layer, self-hosting can give us control over our data and services. But the bill includes updates, monitoring, backups, availability, and incident management. If we administer a server badly, we’ve merely exchanged our dependency on a provider for a dependency on our own ability to keep that server healthy. That’s not always progress.
In communications, protocols such as Matrix and XMPP show that messaging doesn’t necessarily have to mean a single platform: identities and servers can belong to different operators. Federation, of course, doesn’t make moderation, client interoperability, account management, or server maintenance disappear.
Nostr addresses another part of the problem. Users sign events with their own keys and can distribute them through different relays. It’s an interesting model for separating identity from the intermediary that publishes content, but keys still need safeguarding, relays can enforce their own policies, and content availability doesn’t magically become guaranteed.
Then there’s Tor and I2P, which primarily address privacy, routing, and resistance to certain forms of surveillance or blocking. Let’s not mistake them for an absolute guarantee of anonymity: the software, its configuration, and the user’s behaviour remain crucial.
We could go on for pages, but turning this article into a catalogue of projects would be a mistake. The point is different: every technology moves a point of trust. Our job is to understand which one, to whom, and what new responsibilities come with that move.
What if there were no Internet at all?
So far, we’ve discussed how to make services less dependent on a particular operator. Let’s take a more radical step.
No ISP. No DNS. No cloud.
Two people, perhaps in the same local area, need to exchange a message. Do they really need all the infrastructure we’ve grown accustomed to treating as indispensable?
This is where Reticulum comes in.
Reticulum is a networking stack built around cryptographic identities and encrypted communications, designed to operate over different transmission media. It can use IP links, but it can also run over serial interfaces, packet radio, Wi-Fi, and LoRa devices. It isn’t a social network, it isn’t a messaging app, and, above all, it isn’t a ready-made global Internet waiting to replace the one we have.
It’s a set of tools for building networks that can operate without conventional Internet connectivity, provided a physical link or a functioning path of nodes still exists between participants.
That distinction matters. “Without the Internet” doesn’t mean “without infrastructure”. It means being able to decide which infrastructure to use, even when it isn’t the infrastructure of commercial operators.
From Linux to GrapheneOS, over the radio
In the slides for the Linux Day talk I’d prepared, there was a diagram I still like very much. It wasn’t a demonstration performed on stage, but a theoretical architecture intended to start a discussion:
Linux computer running an LXMF client → RNode → LoRa radio link → RNode → Android device running GrapheneOS and Sideband.
Let’s unpack that without skipping steps.
Reticulum handles the communications layer. LXMF is a messaging protocol that can operate over Reticulum. Sideband is a client that makes those capabilities available, including on Android. RNode is a radio interface that can connect Reticulum to LoRa hardware.
LoRa is a radio technology for low-bitrate communications over comparatively long distances, depending on the environment and configuration. It shouldn’t be confused with LoRaWAN, which is a separate networking protocol and isn’t required by this architecture.
The computer doesn’t “send a message to the Internet and hope it arrives”. It uses a configured radio interface. The device at the other end must be reachable directly or through compatible intermediate nodes. Identities, applications, and interfaces must be configured correctly. The recipient can receive the message when a delivery path exists, potentially using forwarding and storage mechanisms provided within the ecosystem.
It’s a fascinating prospect: an encrypted digital message can travel without an account at a cloud service, without DNS resolution, and without a mobile data subscription along the radio path. But it would be misleading to present this architecture as something I’ve already tested, or to suggest that buying two radio modules automatically gives you a reliable network.
It’s a technical experiment worth carrying out, not a commercial promise.
Fortunately, physics doesn’t read manifestos
At this point, the obvious objection arrives: if it’s so interesting, why aren’t we all using it?
Because technological freedom doesn’t abolish physics. Nor does it abolish the work of operating a network.
Available bandwidth on many radio links is limited: expectations should be closer to low-traffic messaging than video streaming. Coverage depends on antennas, obstacles, power, location, and the availability of intermediate nodes. Delivery is not guaranteed at any given moment: without a viable path, a message may have to wait or may not arrive within the expected time.
Key management remains a real responsibility. Cryptography protects communications only within the actual security properties of the protocol and software in use. It cannot protect a compromised device, an identity mistaken for someone else’s, or a vulnerable implementation. The Reticulum project itself cautions against treating its implementation’s security as an absolute guarantee.
There are also rules governing radio spectrum use, which must be checked for the relevant country, frequencies, equipment, and operating modes. And there is hardware and software compatibility: Sideband being available on Android doesn’t guarantee that every combination of phone, cable, adapter, and RNode will work immediately.
Finally, there’s a less obvious issue—particularly relevant to anyone who cares about free software. Reticulum’s reference implementation is currently published under a specific licence that includes restrictions on use. The code is accessible, but it would be wrong to confuse that access with an open-source licence free of field-of-use restrictions under the OSI criteria. This is a project decision worth reading and evaluating, not hiding behind a convenient label.
That isn’t a reason to dismiss Reticulum. It’s another reason to examine it as rigorously as we examine proprietary technologies.
The Sovereignty Stack: six layers, no magic wand
If I had to summarise the entire talk in one diagram, I’d use what I called the Sovereignty Stack.
It isn’t a product or a standard. It’s a way to organise architectural questions:
- Device and operating system: control over devices, updates, attack surfaces, and ownership of credentials.
- Infrastructure: exportable data, recoverable backups, and services that multiple operators could manage.
- Network and communications: open protocols, alternative paths, and the ability to communicate even with degraded connectivity.
- Identity and social connections: keys, portable accounts, interoperability, and freedom to change clients and intermediaries.
- Payments: the ability to receive and transfer value without necessarily handing custody to a central processor.
- Economic activity: service models in which a platform facilitates a relationship without automatically taking control of participants’ identities, data, or funds.
We don’t have to achieve total independence across all six layers to gain something valuable. We can begin with whichever layer currently presents our greatest risk.
For an organisation, that might be database portability. For a journalist, the ability to stay in contact with an audience. For a local community, a communications channel when Internet connectivity fails. For a professional, the ability to receive payments without surrendering control of the funds to an intermediary.
In every case, we have to ask how much we’re prepared to pay—in money and operational effort—to gain more autonomy.
And what happens when it’s time to get paid?
There’s one layer that discussions about decentralisation often leave until last: money.
We can use open protocols to communicate, own our server, and control our keys. And then discover that, to run an activity, we depend on a single intermediary that authorises, holds, or revokes payments.
This is where Bitcoin becomes interesting, beyond arguments about its price. It allows value to be transferred under shared network rules without necessarily requiring recipients to entrust custody of their funds to a platform. It doesn’t eliminate transaction fees, volatility risk, tax obligations, usability problems, or regulatory constraints. And it doesn’t guarantee that every user can always reach the network when connectivity is disrupted.
BTCPay Server brings this model into an application context. A merchant can generate payment requests and receive Bitcoin directly into a wallet they control, without handing the invoicing software their private keys merely to receive on-chain payments. There’s still infrastructure to operate, and Lightning introduces further operational considerations around nodes and liquidity.
At that point, the connection to a project I’m working on, The Orange Cove, becomes almost unavoidable. The architectural idea is simple: a marketplace can help a client and a professional find each other, organise work, and initiate a payment without having to take custody of the professional’s Bitcoin. It’s a project under development, not evidence of commercial success or a guarantee that regulatory obligations do not apply.
The point isn’t to promote a platform. It’s to show that separating the party facilitating a service from the party controlling the funds can be an architectural choice.
It’s as true for money as it is for data: reducing a dependency doesn’t mean eliminating every intermediary. It means preventing an intermediary from automatically becoming the owner of something it was only supposed to transport or coordinate.
Sovereignty has a cost. So does dependency.
I don’t want to end with the usual call to “take back the Internet”, because that makes things sound far too easy.
Running a server requires maintenance. Managing cryptographic keys demands discipline. A radio network needs nodes, coverage, expertise, and often a good deal of patience. Federating services means dealing with anti-spam measures, interoperability, and moderation. Using non-custodial payment systems means taking on responsibilities we would otherwise delegate.
The benefits won’t necessarily outweigh the costs for every person or company. And there’s nothing virtuous about an “independent” solution that becomes unreliable or insecure because nobody has the resources to maintain it.
But there’s another cost we’ve learned not to see: the cost of having no choice. The price of a migration that cannot be performed, of an identity bound to one operator, of an activity that stops because someone has switched off a service we thought would always be there.
That’s why I’m not proposing we throw away the cloud, platforms, or established infrastructure. I’m proposing that we ask different questions when designing something new. Who controls the keys? How much does leaving cost? Which protocols can we replace? What remains operational when the provider changes its mind or the network is unavailable?
The answers won’t all come from Reticulum, Linux, or Bitcoin. No technology, by itself, gives autonomy back to someone who doesn’t understand the dependencies they’ve built.
Code alone isn’t enough. Choices are.
We don’t need to replace the entire Internet. We need to stop—whenever we can avoid it—building systems that a single intermediary can render unusable.
The Internet can still be repaired. But slogans won’t fix it.