@stefano that lighthouse function could be useful in other projects, too, it seems.

@stefano

My only concern is that the relay could be the gatekeeper.

@Linux@planet.moe the lighthouses can be self hosted and you can set multiple ones for failover. The first "official" two will share the same suffix, so they're totally swappable.

@stefano

That works.

As long as someone can take control of their own relay and their own instance, this seems like an interesting idea.

@Linux@planet.moe the same executable that runs the instance can run a lighthouse.

@Linux@planet.moe littleMesh lets a littleFedi instance federate without a public IP address, a
DNS name, or an inbound port: from behind home NAT, behind CGNAT, on a laptop,
on a Pi plugged into a router nobody administers.

It is an additional transport, not a new protocol. ActivityPub, WebFinger, HTTP
Signatures, media fetches and the delivery queue all run over it unchanged.

Two kinds of machine take part:

• a node is an ordinary littleFedi instance that cannot accept incoming
  connections;
• a lighthouse is a small publicly reachable relay that introduces nodes to
  each other and copies encrypted bytes between them. It stores no accounts,
  reads no messages, and hosts no identities.

You need at least one lighthouse somewhere. It can be someone else's, a €3 VPS
of your own, or a machine you already run with a public address.

But we're also planning to run two "public" lighthouses and let the "littlefedi init" process to pre-configure them. Going online will really be a matter of seconds - without even needing a reverse proxy.

@stefano sounds a lot like cloudflared tunnels but more transparent. Cool idea!

@fullywoolly@mastodon.social the idea came both from cloudflared and #DeltaChat relays. Dumb relays, that just interconnect people.

The only difference is that Delta Chat relays store messages, littleMesh doesn't

@stefano I haven't played with delta chat yet. I just got most of the people I talk to on signal and not ready for more pain.

@fullywoolly@mastodon.social @@stefano@rpi0w.stefanomarinelli.it Signal is great, but not decentralised.

@stefano ya it's always made me a bit apprehensive but generally ok with my threat model. Maybe one day I'll push another switch.

@stefano cool! Can you give an example of a handle? Like now I have @ samuel @ social.spejset.org

@stefano hehe, yeah I guess so :)

@stefano will the handle be the same if one switches relay?

@samuel@social.spejset.org unfortunately, the handle will be created and will be the same for the entire lifecycle of the instance. You can change the secondary relays, but not the first one.

But you can multiple relays serving the same handle, so you can have a failover setup.

@stefano ohh, that is prettt neat! Like DeltaChat relays kind of?

@samuel@social.spejset.org Some ideas are similar, but Delta Chat relays have less constraints. The common idea is that the relay cannot read your contents, but littleMesh is (currently) more static than Delta Chat approach. This is because we need to keep compatible with the other ActivityPub implementation and the domain name needs to stay static.

@stefano reminds me of reticulum

@stereo@freiburg.social yes, there are some common points

@stefano This is awesome.

@stefano With littleMesh, will a user’s Fediverse identity be tied to the lighthouse’s domain, or could they use their own domain and switch lighthouses without changing their handle? Avoiding domain lock-in seems important for true decentralization.

@sturai@masto.es It's a mixed approach: you can have your official domain (like example.com) and still federate via mesh. But you (currently) cannot change the domain name, so if your primary use is via lighthouse, you need to stick with the lighthouse's domain (for proper federation). This is because we need to keep compatible with the other ActivityPub implementations and the domain name needs to stay static.

There are some workarounds like you can have more lighthouses and they can have the same domain (we call it suffix).

True decentralisation via total domain name swapping could be feasible but it would only work between littleFedi instances, as Mastodon and other ActivityPub implementations wouldn't support it.

Anyway, we're still trying to find a reliable workaround for this. My dream would be total decentralisation and total migration from one relay to another, like Delta Chat.

We already tested something similar and it worked, but broke federation with other AP implementations.

@stefano Thanks for your response. Excited with this!✊🏻

@stefano @sturai

would be really nice if you offered Federation to Tor v3 Hidden service addresses in addition.. we have the same issue running under tor as those running on rfc1918 addresses behind CGNAT

@hotelzululima@mastodon.social It's planned, and should not be complex to add as it's the same concept as using the mesh with direct connections (no relays involved).

@stefano

Here in Romania I've never seen CGNAT, they give you a seldom changing public ip and ipv6 (works, but i have to find the time to study and review my dns/proxy config for that).

Other software use relays (Holos, nostr..) but it's not something I'm enthusiast about, again, it's a choke.

What about using something like tor ?

@luca@sironi.xyz It's planned, and should not be complex to add as it's the same concept as using the mesh with direct connections (no relays involved).

@stefano but how does the current Fediverse reach the mesh nodes? Are addons required inside the servers? Great Idea!

@pa@zusammenhalt.de there's a gateway (that can be self-hosted) so the mesh nodes can connect to that gateway and it will bridge the connections.