Local timeline
This is my very first blog post. There are many blog posts, but this one is mine.
@farooqkz@bsd.cafe @themipper@mastodon.social @stefano@rpi0w.stefanomarinelli.it I have an Orange PI PC and an Orange PI Zero. I tested littleFedi on both of them (on NetBSD).
@oscarfalcon@mastodon.social @themipper @stefano@rpi0w.stefanomarinelli.it sure, why not? We'll also make sure that it will be easy to install and maintain.
I still find this fact quite amazing, especially seeing as I have required full vps Mastodon hosting for the last 5 years. Just incredible #littlefedi can run successfully on a Pi Zero W
@stefano
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!
@themipper@mastodon.social @stefano@rpi0w.stefanomarinelli.it that will be a perfect platform for it. RAM won't be an issue and the CPU is much more performant than the original zero w
@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.
@mboelen people here are usually sending DMs or local only posts - and that's perfectly fine. I'm usually bookmarking everything and study them later.
@fasnix "worth" is the key here. People often just vomit negative stuff. The question is: is it "worth" sharing?
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 asks in the compose field:
"What is worth sharing?"
Interesting question 🤔
Other clients ask, e.g.:
"What's on your mind?"
(you don't want to know, really 😁)
or
"What are you doing?"
(nothing really, watching my timeline fly by)
Another question could be:
"Have you really thought about what you are about to share with the public / whole wide world?" 🤔
I like the catch-up feature on LittleFedi !
So easy to just take a glimpse of the timeline without scrolling full day 👍
#littlefedi
@stormii@darmstadt.social @HolosSocial@mastodon.social Holos is more oriented towards storing and forwarding messages to you device. This has a more "traditional" approach, while still being light. But yes, there are some similarities.
