Local timeline

Beautiful poem in Interlingua.

"..., an international language. It extracts the common Graeco-Latin vocabulary present in today's languages.

Here is a translation of the poem:

The sky is a canvas
painted only in gray
Raindrops dance
that haven't yet fallen

Little by little
the first drops come,
slowly begins
the percussive struggle

Furious drums
I hear from the roofs,
lying drowsy
in a disheveled bed

The air is full
of the scents of the earth
and my mind of thoughts
that spin and wander

When rain falls,
I whisper your name
and behind the gray sky
I see a light

Leaves bend
with heavy drops
The earth is a mirror
that reflects birds

The fragrance of firs
and of fresh grass
fills the soft
picturesque ground

Clouds – the poets,
write ethereal verses
and winds carry them
slowly to you

I open the window,
hear celestial poems
and perhaps your voice
from the distant forest

But suddenly, in the distance,
the thunder, a brilliance
The lightning wrote
your name to the sky

When you return,
summer will return
Still in spring
I remain abandoned

Little by little
the rain ends
and I say your name:
Kalini, Kalini"
(...)

https://inv.nadeko.net/watch?v=0hlLoysbCPI

(https://youtu.be/0hlLoysbCPI)

#MarcusScriptor #Interlingua #ConLang #Language #Poem #Poetry #Literature

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