@jti42@infosec.exchange The short version is: scope and threat surface.

littleMesh is trying to solve reachability and stable identity for nodes behind NAT, not to build a global discovery system.

For a DHT, the main objection was that it would introduce a whole new class of problems: replication, bootstrapping, poisoning resistance, abuse handling, consistency/consensus questions, etc. And it still would not remove the need for DNS/HTTPS when interoperating with ordinary ActivityPub servers, so the added complexity did not buy us much for the actual problem we were trying to solve.

The directory was intentionally kept much narrower. It is an authority for human-readable aliases and signed reachability information, not an index of users or content. The node identity remains self-certifying, and the directory cannot impersonate it.

Directory federation or a global view was not so much rejected forever as deliberately left out of scope. Once directories start exchanging knowledge, you need to define cross-directory trust, namespace collisions, propagation rules, conflict handling, replay/rollback semantics, abuse controls, and what exactly a “global view” is supposed to contain.

And since the directory does not contain accounts in the first place, federating directories would still not naturally produce a global account catalogue unless we deliberately added an entirely new discovery layer.

For availability, replication is actually more interesting to us than federation: having multiple directory endpoints serving the same signed state is useful because it removes a single point of failure. That is quite different from having independent directories merge into a globally searchable namespace.

So the design bias has basically been: solve the smallest networking problem necessary, keep identity cryptographically independent of the infrastructure, and leave broader discovery to the existing Fediverse mechanisms unless there is a compelling reason to add something else later.

@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.