Stefano on littleFedi

@stefano Created:

It's me, Stefano, the BSD and illumos Cafe Barista - aka @stefano@bsd.cafe and @stefano@illumos.cafe

I'm testing something cool - #littleFedi !

This instance is efficiently running on a Raspberry PI Zero W, powered by #NetBSD.

I'll post general stuff - for more littleFedi news and updates, follow my other profile: @stefano@littleone.littlefedi.social

Let's go!

Visit blog
RSS
380 posts
hidden followers
hidden following

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

@EnigmaRotor@bsd.cafe illuminator! I like it. We may use it for one of the "official" lighthouses we're planning to publicly provide. Thanks for the idea!

@EnigmaRotor@bsd.cafe I'm trying to transform it into "faro", which is Italian, but I'm not the one who can decide here 😆

littleMesh addendum: readable handles and replaceable relays

Yesterday's post left one thing unsolved. Your littleMesh identity is your Ed25519 public key, which is great for security and terrible for a handle: nobody wants to type @alice@a1b2c3...52-characters....mesh.littlefedi.social, let alone read it out loud. And the lighthouse we mentioned, the relay that introduces you to the world, was baked into that identity too. Change relay, and you'd look like a different node.

We've been studying how to fix both, and we think we see a path.

The idea is a small signed directory sitting next to the mesh itself. You'd reserve a friendly alias, something like red-house.mesh.littlefedi.social, and your node would publish a signed record binding that alias to your node ID and to up to three lighthouses. Signed with the same mesh key you already have, no new identity, no new PKI. The record would carry a sequence number and an expiry, so nobody, not even the directory operator, could roll it back to an older version or serve a stale one past its time.

What we like about it is what it wouldn't change. Your handle would stay @alice@red-house.mesh.littlefedi.social, readable. Underneath, WebFinger would still resolve to your real actor ID, the one built from your node ID, exactly as today. And switching lighthouses, would just mean publishing an updated signed record. Same handle. Same actor ID. Nobody following you would notice anything happened.

The directory itself would stay deliberately weak in what it's trusted with. It couldn't produce a valid record for your node ID without your key, and every connection would still authenticate the node ID end to end, so even a malicious or compromised directory could deny service but never impersonate you.

We're building this over the next few days, opt-in, as an experiment. Once it's up, we want to see it survive a real follow exchange with stock Mastodon, snac and GoToSocial, and a lighthouse swap that doesn't touch the handle, before deciding whether it earns a permanent place in littleMesh or gets reworked. Worth trying, not yet worth trusting.

#littleFedi #littleMesh #Fediverse #OwnYourData

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

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

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

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

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

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

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

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

@samuel@social.spejset.org oh, the handle will be "terrible" - something like @@ghngxhtemvno7qyv4a7nejwjj36vh3xgqk5torc7jvpfezss2jyq.mesh.faro.example - but it's the only price to pay to federate from everywhere.

@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

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

littleFedi introducing littleMesh

We've been buried in littleFedi work lately, and there's one piece I want to talk about because it's the one I'm genuinely excited about: littleMesh.

The problem is an old one. Federation assumes you have a domain, a public IP, an open port, a TLS certificate. Fine if you're renting a VPS somewhere. Not fine if your instance lives on a Raspberry Pi in your house, behind CGNAT, with an ISP that will never hand you a real IP address no matter how nicely you ask. Until now, that simply meant no federation for you. Full stop.

littleMesh gets rid of that requirement entirely, without asking you to build any of the infrastructure above.

On first run, your instance generates its own Ed25519 keypair. That key becomes your identity, no domain required, because your instance's address is derived straight from your public key, in the form .mesh.. Then your node opens an outbound connection to a "lighthouse", a small, publicly reachable relay, and registers itself there. Since the connection is outbound, it works from behind any NAT, any CGNAT, with zero port forwarding. The ISP never even notices.

When someone wants to reach you, they ask the lighthouse to open a circuit. The lighthouse introduces both sides, you call back, and it splices the connection together, but it only ever sees encrypted bytes, never your actual traffic.
Once the introduction is made, if you happen to have a reachable address after all, both sides skip the relay and talk directly. If not, the relay just keeps carrying you, quietly, in the background.

And if you already run an instance with a real domain, you can still turn on littleMesh, purely to reach mesh-only instances. Your own identity doesn't change at all.

There will be a default pair of community lighthouses, so you don't even need to find or run your own relay to get started, just say yes during littleFedi init and you're on the mesh.

The fediverse shouldn't require you to be reachable. It should reach you.

#littleFedi #littleMesh #Fediverse #OwnYourData

You’ve just been Rick-rolled!

Good night, world!

Load older posts