Mon 27 May 2024

§NixOS Modules

On Friday we were talking about doing something alternative to Nix, but without a clear statement of the problems with Nix. One clear problem I have with the NixOS ecosytem is the module system. From section 5.1 of the NixOS paper, the module system allows ‘separation of concerns: each module defines a single, “logical” part of the system (e.g., some system service, support for a certain kind of hardware device, or an aspect such as the system path), even though its implementation might cross-cut many “physical” parts (e.g., the derivations that build the boot scripts)’. In one place I can define everything needed for a particular application; I can describe a matrix setup server, reverse proxy, postgres database, dns records, and TLS certificates in one file. And then enable or disable that based on a flag. And I can parameterize all of this by domain name, so I can call it with two different domains to deploy two synapse servers.

However, I have a number of issues with this implementation:

1. This is module system is implemented with the Nix DSL, which includes implemting type checking not in the Nix DSL, but with the Nix DSL. This leads to completely unsable backtraces when you have an error in a NixOS module. If this functionality were part of the language itself it could be a much more usable experience.
2. There is no abstraction over implementations Modules are parameterised by options, but their implementations are exposed. If I have a module with sets systemd.services.my-service.serviceConfig.Environment.PORT = 80 and networking.firewall.allowedTCPPorts = 80, I can override the PORT environment variable in another module, which would leave the firewall misconfigured.
3. It’s possible to have implicit dependancies on other modules.
4. Possiblty as a result of the previous two, in general it’s not possible to instantiate two instances of a service.
5. System state is not considered. Again, from the NixOS paper, modules have to be written to be ‘self- initialising and idempotent’. I read a masters thesis on using a snapshotting filesystem to bring the system state into the fold of the software deployment tool which could be one way to address this.
6. Services are configured only within the scope of a single machine. https://spritely.institute/news/spritely-nlnet-grants-december-2023.html

§Writing

Research question:

How can we modify the Internet architecture to support computing in the physical world.

Hypothesis:

Extending the DNS will allow us to interoperate with existing Internet architecture.

§Reading

§Bigraphs

Read the first chapter of ‘The Space and Motion of Communicating Agents’ by Robin Milner, ‘The Idea of Bigraphs’. The book describes a framework for modelling ubiquitous computing (amoung other applications) with a tree (more specifically a forest) of ‘places’ (i.e. containment), and a graph of ‘links’ between nodes (ie.e connections). It seems very relevant to Spatial Networking, although I’m not quite sure how to apply it yet. One initial idea is mapping our onto a concept of containment, which gives a heirarchy of naming like in the DNS. And with bigraph compisition you could hang a whole subdomain organisation off a different TLD. Bigraph reactions could model. All in all I like having this theoritical underpinning to put my thoughts into. For example, the idea of offline operation and intermitent connectivity could be modelled with bigraph reaction rules. Anil pointed me to Real-time verification of wireless home networks using bigraphs with sharing as an example of it employed in networking. I’m planning on reading chapter 2 next for a formal definition of bigraphs.

§Matrix Spec

I read the Matrix spec overview:

Matrix defines a set of open APIs for decentralised communication, suitable for securely publishing, persisting and subscribing to data over a global open federation of servers with no single point of control. Uses include Instant Messaging (IM), Voice over IP (VoIP) signalling, Internet of Things (IoT) communication, and bridging together existing communication silos - providing the basis of a new open real-time communication ecosystem. … The end goal of Matrix is to be a ubiquitous messaging layer for synchronising arbitrary data between sets of people, devices and services - be that for instant messages, VoIP call setups, or any other objects that need to be reliably and persistently pushed from A to B in an interoperable and federated manner.

Of particular relevance is how Matrix is reliant on the DNS for identity:

Each client is associated with a user account, which is identified in Matrix using a unique “user ID”. This ID is namespaced to the homeserver which allocated the account and has the form: localpart:domain?

Events exchanged in the context of a room are stored in a directed acyclic graph (DAG) called an “event graph”. The partial ordering of this graph gives the chronological ordering of events within the room. Each event in the graph has a list of zero or more “parent” events, which refer to any preceding events which have no chronological successor from the perspective of the homeserver which created the event.

From attending Interoperability & Matrix I know that Linearized Matrix reduces this flexibility.

§Where on Earth is the Spatial Name System?

The idea is to give a global name to every ‘spatial’ (ubicomp) device based on its location in order to particpate as a first-class citizen of the Internet. We resolve these names to a whole bunch of addresses beyond IP for link-local communication, with the nameserver acting as a resgistry for these methods. Names are allocated acording to the heirachical nature of civic locations (like bigraph place trees) to give unique names to each device. Depending on whether you’re outside a spatial domain or inside, split-horizon resolution can return you context-dependant results (how can this be modelled with bigraphs reactions). We also mention how resolution of a physical space could be supported with ‘geodetic resolution’. The key point is that this interoperates with existing Internet infrastructure and applications as it extends the DNS.

§Coding

It’s been a coding light week, but I’ve previously:

• Added NixOS depext support to Opam: https://github.com/RyanGibb/opam/pull/1
• Deployed Eon’s TLS provisioning NixOS module onto my server. This could be used to provision TLS certificates for spatial devices.
• Which NixOS / Eilean I can create ISOs to deploy onto e.g. a spatial device, which could then register itself with the namserver via a capability.

§Next week

• Read chapter 2 of Bigraphs.
• Read “Real-time verification of wireless home networks using bigraphs with sharing”.
• Have a go at supporting some SNS extensions in Eon.
• Use Eon TLS provisioning for a spatial device.