Here is another unfinished idea, fresh from this morning, to workaround the problem of domain names in the context of horizontal communities.
It solves two problems:
- Takeover by a single individual, by way of a distributed secret between community members
- Centralized self-hosted services, by way of identical reverse proxies, each under the control of a different community member and periodic backup resurrections
Shared control of a domain name
- Enable TOTP 2FA on a registrar
- Setup a shared TOTP app that can only be accessed if N individuals agree (https://en.wikipedia.org/wiki/Shamir's_Secret_Sharing or something)
This is not convenient but domain name changes are very rare therefore it is not an inconvenience that could impact the productivity of the software project. Assuming the project has a manifesto similar to fedeproxy, the group of individuals controlling the domain need to agree to a change otherwise none of them can do it.
Decentralization via reverse proxy
The domain points to a reverse proxy (first tier) that has two types of backend:
- non-federated self-hosted services: each person sharing control of the domain runs an identical reverse proxy (second tier). Rose has no control over Jean’s reverse proxy or Edith’s reverse proxy. These second tier reverse proxy are all configured in the same way: their backend are the same self-hosted services. The first tier reverse proxy randomly chose one of the second tier reverse proxy when forwarding a request.
- federated services: the first tier reverse proxy has a backend that randomly chose one of the federated services. They are synchronized in real time and it does not matter which one handles the request.
federated services non-federated self-hosted services
+--------+
+---------+ | Reverse| +-------------+
| Forge |<-------------+ +---------->| Proxy +---------->| |
| Jean | | | | Jean | | |
+---------+ | | +--------+ | |
| | | Chat |
+-+--------------+-+ +--------+ | |
+---------+ | | | Reverse| | |
| Forge |<-----------+ Reverse +---------->| Proxy +-------->| |
| Rose | | Proxy | | Rose | | |
+---------+ +-+--------------+-+ +--------+ | Website |
| ^ | | |
| | | | |
| | | | |
+---------+ | | | +--------+ | |
| Forge |<-------------+ | | | Reverse| | Forum |
| Edith | | +------>| Proxy +-------------->| |
+---------+ +------+------+ | Edith | | |
| example.com | +--------+ +-------------+
| |
| registrar |
+-------------+
^
+-----------------------+
| Rose & Jean & Edith |
| |
| Shamir Secret |
+-----------------------+
Data portability via backup resurrection and infrastructure as code
Jean, Rose and Edith are trusted with a full backup of the services (i.e. the horizontal community agreed). At a given point in time one of them runs the backends used by the second tier of reverse proxy. On a regular basis the services are migrated under the control of someone else, to verify resurrecting services from backups actually works. The second tier of reverse proxy are re-configured to use the newly instantiated backend.