Eilean (ˈelan) – Scots Gaelic: island.
Our digital lives are increasingly fragmented across numerous centralised online services. This model concentrates power, leaving us with minimal technical control over our personal data and online identities. The long-term permanence of these platforms is uncertain, and their commercial incentives are often misaligned with user interests [1].
We propose inverting this model: instead of centralising our data in proprietary silos, let’s centralise our presence under our own control using open, federated services. We introduce the concept of ‘digital islands’, or Eileans – self-hosted hubs for an individual’s or community’s online presence. By hosting services ourselves, we regain autonomy and control.
Eilean is a project designed to simplify the creation and management of these digital islands. The core idea is to parameterise a complete operating system deployment by a domain name and a desired set of services. This allows users to easily deploy their own instances of federated services like Matrix, Mastodon, Bluesky’s AT Protocol [2], and E-Mail.
We utilise NixOS to enable declarative, reproducible configuration and deployment of these services. This provides strong guarantees about the system’s state. Eilean originated from my personal NixOS configurations for self-hosting, spun out on 1 Dec 2022. (Do get in touch if you’re keen on trying it out.)
However, while NixOS is great for declarative OS configuration, it presents challenges for:
Managing mutable state
Secrets: The Nix store is world-readable (Nix PR #329), making direct embedding of secrets problematic. Secure secret injection and rotation require external mechanisms like agenix or sops-nix.
Network: Services implicitly depend on resources such as IP addresses, domain names, or certificates. For example, while HTTP servers can provision certificates with ACME’s HTTP challenge for public-facing services, provisioning TLS certificates for services behind firewalls or NAT requires DNS challenges and manual integration with DNS providers.
Data: NixOS doesn’t manage application data lifecycles like database schema migrations. Though interesting work has been done to manage runtime state with the software state using snapshotting filesystems [3].
Runtime service management
- Dynamic reconfiguration: Changing service parameters often requires a time-consuming NixOS evaluation and rebuild, and frequently involves downtime (breaking before making).
Multi-machine coordination: Deploying and coordinating services across disparate machines requires mechanisms beyond standard NixOS tooling.
Auto-scaling: If a service runs out of, say, storage space, it should be able to automatically provision more. If the load on a service is too high, it should be able to duplicate itself and split the work.
Cross-ecosystem packaging: Nix excels at system-level reproducibility but struggles with the scale and versioning complexities of diverse language ecosystems (lacking built-in version solving like most language-specific package managers).
Tools like Docker Compose and Kubernetes offer more flexibility in dynamic runtime management but often sacrifice the strong reproducibility guarantees provided by Nix.
To address these limitations, we are exploring several approaches:
Capability-based resource management: We’ve extended Eon with a Cap’n Proto capability-based RPC interface for managing network resources. Currently, it offers capabilities for:
- DNS management: Allowing secure delegation of DNS zone control for dynamic updates and propagation to secondary nameservers.
- TLS certificate provisioning: Enabling services (even those not publicly accessible or running HTTP servers) to obtain certificates via the ACME DNS challenge. Eilean heavily utilises this through a custom NixOS module.
This capability model could be extended to manage other resources like secrets or storage, providing a unified RPC interface to write more integrated and composable networked applications.
Cross-ecosystem packaging: Enki aims to bridge this gap by resolving package dependencies across ecosystems and preparing them for deployment via Nix or otherwise.
Modern containerisation: To able the dynamism required for our runtime service management, as well as security, a service manager should isolate services, such as
systemd-nspawnusing Linux namespaces. Patrick’s work on shelter is promising as a potential foundation for lightweight, secure containerisation.
If we can create something to fulfil these criteria, could this model apply elsewhere? We envision creating composable applications and self-managing systems built upon this basis.
Decentralised infrastructure: Could devices like Raspberry Pis, old Android phones, or ESP32 chips act as remote sensors or nodes in a larger, self-managing system? I’m interested in this as infrastructure for spatial computing.
A Self-healing OS: Can we build systems that automatically manage their resources and runtime state, dynamically provisioning resources, and healing from failures?
- Distributed capabilities: Expanding the capability RPC model could lead to more sophisticated distributed systems where resources are securely shared and managed across hosts and domains. GNU Shepherd’s port to Guile Goblins using the OCapN protocol (similar to Cap’n Proto, who are in the standardisation group) is a really interesting development here.
I also have some issues with the NixOS module system and the Nix DSL and am interested in an OCaml interface to the Nix store.