@jti42@infosec.exchange Absolutely. The documentation I mentioned is actually part of the project itself, so it will be released together with littleFedi/littleMesh once everything is ready. It includes the architecture overview, protocol details, identity model, directory design, threat model, and the reasoning behind some of the choices.

So I cannot link it publicly yet, but I definitely will once the project is released.

And yes, with one important distinction: the directory is not intended to be an account directory or a global discovery mechanism.

It only maps a readable node alias to its stable Ed25519 node ID, and a node ID to its current signed lighthouse locators. It stores no information about the accounts hosted by that node.

So enabling the directory does not create an encompassing view of users across the mesh. Account discovery remains the normal Fediverse/WebFinger/ActivityPub business once you know what you are looking for. The directory only helps you get from a human-readable mesh name to the technical node identity and then to a route to that node.

Also, at the moment directory instances do not federate or exchange their contents with each other. A node publishes to a particular directory, and a gateway/client configured for that directory knows what that directory knows. There is deliberately no DHT-like propagation or global mesh-wide index.

The Matrix comparison is interesting, though. There are certainly some similarities in separating identity, discovery, and routing concerns, although littleMesh is considerably narrower in scope: it is primarily a transport and reachability layer for ActivityPub rather than a new application-level federation protocol.

@jti42@infosec.exchange It's closer to an authenticated circuit/rendezvous relay than either a glorified STUN/TURN setup or a Kademlia-style overlay.

There is deliberately no DHT and no distributed routing/discovery protocol. A node keeps an outbound connection to one or more lighthouses. When another node wants to reach it, the lighthouse establishes a circuit between them, but the actual peer-to-peer session is end-to-end TLS inside that circuit, pinned to the nodes’ Ed25519 identities. The lighthouse therefore relays ciphertext rather than terminating the peer session.

If direct connectivity is available, peers can also discover and use the direct path, bypassing the lighthouse.

There is an optional directory, but it isn’t a DHT either. It holds signed records mapping a stable node identity to its current pinned lighthouse locators, mainly so relays can be replaced without changing the node’s identity, and to support readable aliases.

And yes, there is documentation beyond "read the code" 😉
The littleMesh documentation describes the architecture, circuit establishment, identity model, directory protocol/API, gateway, failover and trust/security model. There's also a separate littleMesh v2 identity study covering the protocol design decisions and threat model in more detail.

Just a little reminder on littleFedi's efficiency

The instance https://rpi0w.stefanomarinelli.it - with my user @stefano@rpi0w.stefanomarinelli.it - has been running for over a month on a Raspberry Pi Zero W powered by NetBSD.
Under normal operation, it uses 58 MB of RAM, including caches. And it shows no signs of slowness!

#littleFedi #NetBSD #RunBSD #OwnYourData