# 27 May. 2024

Previous: [20 May. 2024](/2024-05-20.md)
Next: [24 Jun. 2024](/2024-06-24.md)

## 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](https://edolstra.github.io/pubs/nixos-jfp-final.pdf),
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](https://github.com/NixOS/nixpkgs/blob/master/lib/modules.nix)
    with the Nix DSL, which includes implementing [type
    checking](https://github.com/NixOS/nixpkgs/blob/master/lib/types.nix)
    not in the Nix DSL, but *with the Nix DSL*. This leads to completely
    unusable 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 dependencies on other modules.
4.  Possibly 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](http://denbreejen.net/web/thesis.pdf) 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](https://eprints.gla.ac.uk/84836/1/84836.pdf) 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](https://fosdem.org/2024/schedule/event/fosdem-2024-3157-interoperability-matrix/)
I know that [Linearized
Matrix](https://datatracker.ietf.org/doc/html/draft-ralston-mimi-linearized-matrix-03)
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.


