Stefano on littleFedi

https://rpi0w.stefanomarinelli.it/@stefano

It's me, Stefano, *the BSD and illumos Cafe Barista* - aka Stefano Marinelli (npub1ef5…gcpc) and Stefano Marinelli (npub1gac…4w3w)

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 Marinelli - littleFedi (npub1pn5…4tzd)

Let's go!

Public Key

npub1a8mpglhtg5h2elcu6k8w80ghjvpan9wpla67swmphpp2v9nwkp4s7dcdsn

NIP-05 Address

[email protected]

Profile Code

nprofile1qqswnas50m452t4vluwdtrhrh5texq7ejhql7a0g8dsmss4xzehtq6cpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dstu6t73

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1a8mpglhtg5h2elcu6k8w80ghjvpan9wpla67swmphpp2v9nwkp4s7dcdsn

Show more details

Last Notes

2026-09-01 21:51:15 GMT

As it often happens when the day has been long and full, I’m tired but cannot sleep.
To be honest, I don’t want to sleep. Now that I can slow down…sleep?
Oh well, I’d better to.
Goodnight, world!

2026-08-31 17:39:47 GMT

Now on an Orange Pi One, powered by NetBSD, on an external USB drive.
Yes, the storage speed *makes* a difference.
#littleFedi

2026-08-30 20:40:36 GMT

- reply

dopo la foto ce ne ho messo anche di più. Si capisce che mi piace, eh?

2026-08-30 20:25:17 GMT

- reply

that’s strange. It’s probably backfilling old posts but in a wrong way. I’ll check, thanks!

2026-08-30 20:24:10 GMT

- reply

I am

2026-08-30 20:18:53 GMT

- reply

made one by one by my mother, cooked by my wife. The taste is great, but the love you feel is much, much more intense.

2026-08-30 20:11:34 GMT

Some tortellini, just for you
#food
https://rpi0w.stefanomarinelli.it/media/01a0544c-692b-7af7-958b-a2e0caed0c9f/image.jpg

2026-08-30 19:04:33 GMT

2026-08-30 17:58:26 GMT

- reply

not *yet* 😉

2026-08-30 17:53:22 GMT

- reply

"hello, big brother"

2026-08-30 15:35:27 GMT

- reply

this is absolutely true. To be fair, the encryption we use today is much more complex (even if often hardware assisted) than the one we used 20 years ago. Still, software is generally bloated.

2026-08-30 14:00:31 GMT

- reply

Yes, the performance here is on a totally different league. No difference from the #littleOne instance on the VPS.
So I can say that armv7 is giving an optimal experience.

2026-08-30 13:42:59 GMT

- reply

PS: the dirt is a bonus 😆

2026-08-30 13:42:41 GMT

Now on a **Raspberry Pi Zero 2 W** - powered by **NetBSD** (*armv7*) - with an USB ethernet card, as the internal wifi seems to lock when the traffic goes up.
It's *blazing fast*
#littleFedi #Fediverse
https://rpi0w.stefanomarinelli.it/media/01a052e8-656f-795b-8669-edd00fcc45a6/image.jpg

2026-08-30 12:09:29 GMT

- reply

it will be released after EuroBSDCon 😉

2026-08-30 11:53:15 GMT

- reply

I still have four of those A+. They’ve been on for more than 10 years and still rocking!

2026-08-30 11:31:59 GMT

- reply

it does!

2026-08-30 10:13:41 GMT

**...let's lower the barriers even further!**
Now this instance is running on a **Raspberry Pi A+** (*1 core @ 700 MHz, 256MB RAM*), so even less than the Raspberry Pi Zero W it was running on before.
**On NetBSD, of course!**
#littleFedi #NetBSD #RunBSD #OwnYourData #Decentralization #OwnYourVoice
https://rpi0w.stefanomarinelli.it/media/01a05228-7c1a-71a9-ba38-66dfddd51bed/image.jpg

2026-08-30 06:56:30 GMT

Good morning, #Fediverse.
Have a great Sunday!
#Weekend

2026-08-29 10:58:17 GMT

- reply

it's like Mastodon/Akkoma - it will only notify the original author

2026-08-29 10:29:09 GMT

- reply

Exactly. Five minutes later, he/she was sleeping 😉

2026-08-29 08:09:18 GMT

**We all share the same planet**
#note13cc…3ukq

2026-08-29 07:49:44 GMT

Posting this little friend of mine from my tiny instance, running on a Raspberry Pi Zero W with NetBSD.
I'm hoping for lots of interactions, partly because I'd really like to see how far this little setup can go. 😉
But there is also a story behind this photo.
This little one was born free. For quite a long time I used to meet them almost every day, and I watched them grow up. They would come towards me, always keeping a little distance, and meow at me in that friendly way cats sometimes do.
This is the last photo I have, taken just before the Covid lockdowns.
When we were finally allowed out again, I never saw this little one, or any of their brothers and sisters, again.
I like to imagine that during those strange months they simply enjoyed having the world a little more to themselves. Wandering around freely and peacefully, without too much human interference.
And then perhaps they grew up and moved towards the little woodland they always liked to visit, living a free, happy and full life there.
Wherever you are now, hello, little one. ❤️
#Caturday #CatsOfFediverse #CatsOfMastodon
https://rpi0w.stefanomarinelli.it/media/01a04c7e-e62a-7233-b19d-8db5ec6e2484/image.jpg

2026-08-28 20:43:04 GMT

- reply

this is something I’d like to study

2026-08-28 14:54:23 GMT

- reply

on littleFedi you can disable media caching, just leaving the proxying on (if you want to)

2026-08-28 14:53:07 GMT

- reply

Running it on Android is another thing I'd like to try.

2026-08-28 14:52:43 GMT

- reply

littleFedi allows to just proxy the images, so it won't store remote media locally. It will just proxy the requests, so the remote instances will see them coming from your instance, not your client. Or you can disable it and just request the remote media from the originating instances. That way, you don't need a huge media folder, just a small one to store local media files.

2026-08-28 13:39:12 GMT

- reply

GoToSocial will also reprocess (by default) all the media files, and that will use resources.

2026-08-28 13:36:55 GMT

- reply

no. But we have a "low power mode" that will lower some specific settings.
*The preset selects one database connection and one queue worker, a bounded memory cache, one image decoder, a 13 million pixel bound on decoded images (enough for a 4032 by 3024 phone photo), a 1600 pixel cap on stored uploads, cheaper thumbnail resampling, and no dynamic gzip.*

2026-08-28 13:29:56 GMT

- reply

In a world of Goliaths, we are David.

2026-08-28 13:28:59 GMT

**littleFedi doesn't need a Raspberry PI to run.**
It *can* run on a Raspberry PI - and this is totally different.
#littleFedi #Fediverse #OwnYourData
#note10wt…0auz

2026-08-28 13:26:52 GMT

- reply

You're totally right. I'll prepare something for tomorrow's caturday

2026-08-28 13:02:29 GMT

**Thank you, friends!**
The instance held up perfectly, without flinching! I also took advantage of the surge to identify a few areas for improvement, and they've been pinned down. New patches will be rolled out over the next few days.
**The release is getting closer and closer...**
#littleFedi #Fediverse #OwnYourData

2026-08-28 11:22:28 GMT

- reply

yes, it does

2026-08-28 09:57:28 GMT

- reply

mmm...maybe I should contact the Raspberry PI company and ask for some money for (indirect) sponsorship 😆

2026-08-28 09:56:53 GMT

- reply

From my own direct experience (strictly anecdotal and humorous): the more competent someone is and the further they are in internal ops, the less they need powerful or recent hardware.

2026-08-28 07:42:46 GMT

- reply

it seems to be still alive!
https://rpi0w.stefanomarinelli.it/media/01a04752-3344-7b5e-9da1-263f7a57b4bb/image.jpg

2026-08-28 07:25:01 GMT

- reply

"is there anybody out there?"

2026-08-28 06:17:31 GMT

- reply

why not? If it runs a normal OS, it can run littleFedi

2026-08-28 06:13:38 GMT

- reply

😉

2026-08-28 06:13:13 GMT

- reply

the faq will clarify: https://littlefedi.org/faq.html

2026-08-28 06:10:09 GMT

- reply

the future *we* can build

2026-08-28 06:09:03 GMT

- reply

it is!

2026-08-28 06:08:37 GMT

- reply

if you want to, I can create an invite code for you in the littleOne instance, so you can test it

2026-08-27 20:00:55 GMT

...and this is how it's doing, while *many* of you are boosting, replying, etc:
```
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
7745 little 35 0 620M 152M RUN 140:14 57.71% 57.71% littlefedi-armv6
```
Crazy, isn't it?
#littleFedi #Fediverse #OwnYourData

2026-08-27 19:10:03 GMT

This post received *a lot* of comments and reactions, which is great!
It also proved that my little Raspberry Pi Zero W, powered by NetBSD, could handle the load.
Now - to help me test how much load it can tolerate - **please boost and react to this post!** 🚀
#FediTest #littleFedi #OwnYourData #NetBSD
#note1re8…y43f

2026-08-27 18:48:58 GMT

Yesterday’s post received an unexpected amount of appreciation, and the little Raspberry Pi Zero W didn’t even flinch.
#littleFedi #Fediverse #OwnYourData #NetBSD
https://rpi0w.stefanomarinelli.it/media/01a0448d-c8e6-79c9-80b6-4146192e29bd/image.png

2026-08-26 13:23:08 GMT

# This is the first genuinely operational littleFedi instance.
It has been online since 1st July, is single-user (just me), and runs on a Raspberry Pi Zero W powered by NetBSD, directly on its SD card.
**It consumes just under 1W.**
Its database is this size:
`-rw------- 1 little wheel 109289472 Aug 26 15:14 littlefedi.db`
That is, just a little over 100 MB. *Yes, MB.*
Its average CPU load is extremely low.
It is perfectly usable both from the web interface and from Mastodon API apps.
I have 179 followers and 169 followings, and it doesn't bat an eye.
I promise myself to use it more, and I will.
**You don't need Big Tech to communicate with others.**
**You don't need an expensive data center to exist online.**
Because we are people, and the bits are just extensions of our voice.
#littleFedi #Fediverse #OwnYourData
https://rpi0w.stefanomarinelli.it/media/01a03e3d-17cf-7ca9-b131-38c0eb74da0e/image.jpg

2026-08-22 20:54:05 GMT

Current pow.
Somehow #Caturday style, I guess
https://rpi0w.stefanomarinelli.it/media/01a02b40-223d-76af-8218-9ff83e5f9d38/image.jpg

2026-08-14 13:12:22 GMT

**stefano@MBPProM1 ~/s/smolBSD (main)>** ./startnb.sh -i images/rescue-evbarm-aarch64.img
➡️ using QEMU version 11.1.0
➡️ using kernel kernels/netbsd-SMOL-aarch64.img
➡️ using console: com
➡️ using disk image images/rescue-evbarm-aarch64.img
🔚 ^D to stop the vm, ^A-X to kill it
qemu-system-aarch64: warning: driftfix 'slew' is not available with this machine
boot NetBSD/aarch64
initarm
\[ 1.0000000\] NetBSD/evbarm (fdt) booting ...
main
\[ 1.0000000\] smolBSD 11.0\_STABLE (MICROVM) Notice: this software is protected by copyright
\[ 1.0000000\] Detecting hardware...\[ 1.0000030\] WARNING: system needs entropy for security; see entropy(7)
\[ 1.0000030\] done.
**\[ 1.0080588\] kernel boot time: 121ms**
Created tmpfs /dev (1359872 byte, 2624 inodes)
Impressive!
#smolBSD #NetBSD #RunBSD

2026-08-14 05:18:28 GMT

Good morning, world!

2026-08-13 06:07:56 GMT

Good morning, world!

2026-08-10 17:02:03 GMT

Me, looking at the email queue that needs answering...
Also me, spotting a bug in littleFedi - then noticing **Mastodon 4.7.0 beta** just dropped, and realising it's time to schedule the update for **BSD Cafe** and **illumos Cafe**.
One quick `ssh` later, and **BSD Cafe** is updated...
As for **illumos Cafe**, that's going to take a bit more effort (*the process on illumos is slightly different, and that blog post has been waiting for over a year*).
Yeah, I should probably go for a walk...
#IT #SysAdmin #BaristaForever

2026-08-10 07:52:25 GMT

Good morning, world!
Coffee... done!
Morning checks...done!
Let's get ready for a new week!
#NewWeek #MondayMood #HappyNewWeek

2026-08-09 07:53:02 GMT

We definitely need more peace.
Have a great Sunday, #Fediverse!
#note1v69…yw70

2026-08-08 13:41:43 GMT

The EGA version of "The Secret of Monkey Island" showed this sunset in the first part, which then turned into night.
This was not replicated in later versions with higher resolution.
Sometimes it's true: fewer graphics meant more effort and imagination in communication and emotional impact.
#RetroGaming #Gaming #Art
https://rpi0w.stefanomarinelli.it/media/019fe19b-9ac5-7ec2-947b-ea8e83ff4029/image.jpg

2026-08-05 10:01:37 GMT

- reply

the first instance is up. Some more configuration fixes and I'll contact all the people who replied here, with instructions on how to join.

2026-08-04 15:48:40 GMT

# Calling all testers: littleFedi test instance coming soon
I will be launching a test instance of **littleFedi** soon.
If you would like a test account, reply to this post and I will reach out as soon as it is ready.
The goal is to test the platform with a larger group of users and gather initial feedback.
#littleFedi #Fediverse #BetaTesting

2026-07-29 16:38:52 GMT

# 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 *@[email protected]*, 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 @[email protected]**, 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

2026-07-28 19:27:39 GMT

- reply

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.

2026-07-28 19:20:35 GMT

- reply

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

2026-07-28 19:02:55 GMT

# 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 <your-node-id>.mesh.<suffix>. 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

2026-07-27 22:18:36 GMT

You’ve just been *Rick-rolled*!
#note104z…84gk

2026-07-26 07:00:15 GMT

This is the mobile web interface of #littleFedi. It can also be installed as a PWA, with push notifications.
#Fediverse
https://rpi0w.stefanomarinelli.it/media/019f9d39-33a5-721d-8de2-97cc534f31f9/image.png

2026-07-25 07:36:54 GMT

# The Blog Option in littleFedi
littleFedi, like many social platforms, had both a strength and a limit. Posts, by their nature, are ephemeral. They get published, federated (unless local-only, which littleFedi handles) and then, over time, lost. Partly through self-deletion, partly through their normal blending in with the thousands of other posts that pile up over time. Sometimes, though, we want something to stay. And not just stay as a social post, but as an actual blog. A bit like with BSSG, I had thought it would be convenient to have a minimal system. Not to compete with WordPress or other solutions, but to have a small blog, integrated into littleFedi, that would produce and serve a blog updated every now and then, whenever the person writing felt like doing it.
And that's why the blog option was born.
The idea is simple: when you write a post, from the web UI or from the CLI, there's a checkbox, "blog post". If you check it, that post stops being just a status that will scroll past and disappear. littleFedi renders it into a real static site. No JavaScript, just HTML and CSS, an Atom feed, tag pages, a chronological archive. Nothing exotic, nothing that needs maintenance five years from now.
The blog isn't a parallel system you have to feed separately. It's not an export, not an import, not a bridge to some other CMS. The post you wrote is the blog post. Same database, same act of writing, still boostable, still repliable, still part of the conversation on the fediverse side. The blog is just a second representation of the same content, generated automatically. Every time you create, edit, or delete a blog post, the whole static site for your account gets rebuilt from scratch, and the new version replaces the old one atomically, so nobody ever lands on a half-built page. If the build fails, the previous version stays in place. Simple, but it has to work reliably, or the whole idea is pointless.
That's the core of it: two representations of the same post. As a status, it lives in the fediverse, interactive, part of the conversation, subject to replies and boosts like anything else. As a static page, it lives on the web, durable, indexable, with a permalink, something an RSS reader can hold onto. You don't have to decide in advance which posts deserve to last. You write normally, and if something turns out to be worth keeping, you flag it, and it gets its own page.
One detail I cared about while thinking this through: the generated site has to be self-contained. When littleFedi builds it, media gets copied or hard-linked into the generated directory - images, audio, video. If it's stored on S3, it keeps its public URL directly. Either way, the point is that the site on disk doesn't depend on the instance staying up. If the server goes down tomorrow, the blog files are still a complete, working website. That wasn't an afterthought, it was one of the requirements from the start.
Not every account gets a blog, and that's intentional. The instance admin has to enable the feature globally (`[blog] enabled = true`), and then grant it per account. It's not meant to be a CMS, and I didn't want it to become one. Blog posts can't be replies, can't be boosts, have to be public and top-level. These are constraints, not missing features: the blog is for your own writing, not for threads or reshared content.
There's no JavaScript anywhere in the generated site. That was deliberate too. It loads fast, it works offline if you cache it, and it will still render correctly in ten years without anyone having to update a dependency.
In the end, the blog option doesn't ask you to choose between writing socially and writing something permanent. You keep writing the way you always do, on littleFedi, and if a post is worth keeping, you check a box. No separate platform, no migration, no vendor lock-in. Just your own posts, some of them rendered into a small static site you can host anywhere, built out of something that already existed on the open web.
Remember: all this is being currently served by a Raspberry PI Zero W powered by NetBSD
Here's the result: https://rpi0w.stefanomarinelli.it/@stefano/blog/691cb62e-e7a1-434b-ba65-d059ee58ac41/
#littleFedi #SSG #BSSG #OwnYourData #Blogging #Fediverse #NetBSD

2026-07-24 17:43:03 GMT

This photo, from 2015, will self destruct in 24 hours from now.
#littleFedi #Pizza #Food

2026-07-22 11:48:35 GMT

One thing I’ve learned over the years is that you have to test stuff on slow, underpowered hardware.
That’s where bottlenecks, inefficiencies, and bugs show up.

2026-07-21 17:11:34 GMT

**Coming soon...**
*littleFedi*
https://littlefedi.org
#littleFedi

2026-07-21 10:25:19 GMT

Over the past few days, a few crickets have made their way into the house.
Whenever I can, I guide them back outside so they don't land on us during the night.
This morning, I was mowing the lawn a bit - not much, just as much as needed, before the rain - and there were plenty of them in the garden.
A neighbour, as often happens, suggested I cut it shorter "to drive the crickets away". I looked around: all my neighbours' lawns are kept extremely short, and the surrounding countryside is completely plowed.
"And where are the poor crickets supposed to go?"
"They'll find somewhere else."
I put the lawnmower away and decided that, in my garden, they are more than welcome.
#Gardening #Nature #Summer

2026-07-17 14:18:29 GMT

*The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.*
**Edsger W. Dijkstra**
#Quotes

2026-07-12 10:49:43 GMT

- reply

When I read 'electron', all my hair falls out.

2026-07-11 20:37:03 GMT

Just a friendly reminder that this instance is running on a Raspberry Pi Zero W powered by NetBSD and littleFedi (not yet released)
#NetBSD #littleFedi #Fediverse

2026-07-10 19:04:36 GMT

There's some air, warm air. But there are some clouds, too. Dark clouds.
Maybe tonight we'll hear some rain...
#Weather #Summer

2026-07-07 17:52:20 GMT

Just had a shower.
Just started sweating again.
Yes, we're inside a heat wave. Again. 🥵

2026-07-06 08:20:11 GMT

I promised it, so here it is. This is a recording of littleFedi running on a Raspberry Pi Zero W on NetBSD.
#littleFedi #NetBSD #OwnYourData
#note1w0m…5d87

2026-07-04 20:48:46 GMT

Tomorrow, I will make a video of how littleFedi runs on this Raspberry Pi Zero W powered by NetBSD.
Once the caches are warm, the performance is incredible.
#littleFedi #NetBSD

2026-07-04 13:41:05 GMT

- reply

Your art is amazing. Amazing!

2026-07-03 13:37:34 GMT

- reply

oh, do you want a photo of me in bikini? Are you *really* sure you want it?

2026-07-03 13:27:50 GMT

This is mostly a test, tagging some Exquisite friends for a short check: @npub1prm…rs6z @npub1y90…900y @npub1p4e…qzxy
Here's a part of the "beautiful" work done by the FTTH people...
#FTTH

2026-07-01 16:39:40 GMT

Admin interface - queue management
#littleFedi #Fediverse

2026-07-01 15:58:03 GMT

## LittleFedi: light, yet complete
I'm writing this post from a Raspberry Pi Zero W - 512 MB RAM, single-core ARMv6 - running NetBSD, powered by littleFedi. The process sits at 33 MB RSS, CPU basically asleep:
```
load averages: 0.05, 0.08, 0.09
CPU states: 0.0% user, 0.0% nice, 0.0% system, 1.0% interrupt, 99.0% idle
Memory: 301M Free
PID COMMAND RES STATE
2082 littlefedi-armv6 33M kqueue
```
No Redis. No PostgreSQL (but optional). No Sidekiq. No Node.js build pipeline. One statically-linked binary, one SQLite file, and the full fediverse experience. And this is the part people tend to miss: the same binary that runs happily on a Pi Zero scales, on the right hardware, to numbers that have nothing to do with "lightweight". It's not a toy that stays a toy. It's built to grow when you need it to.
### What LittleFedi actually ships
**Federation** - Full ActivityPub S2S: WebFinger, NodeInfo 2.1, host-meta, HTTP Signatures with anti-impersonation checks. Per-user and shared inboxes, outbox, followers, following, featured collections. Thread completion with bounded on-demand fetching of missing ancestors/replies (separate sync and background budgets, all hard-capped). Quote posts via FEP-044f with the full approval handshake (`QuoteRequest` -> `QuoteAuthorization`), matching Mastodon 4.4 semantics, plus `_misskey_quote` and Fedibird `quoteUri` aliases. Account migration (`Move`), both outgoing and incoming, with `alsoKnownAs` linking, automatic follower migration, follow import from AP collections, and CSV export/import. Remote interaction discovery - async like/boost resolution from origin servers with REST fallback.
**Mastodon API** - Broad coverage: timelines (home, public, local, hashtag, bubble, direct), status CRUD with edits, scheduled posts, polls, bookmarks, lists (with `replies_policy` and `exclusive`), filters v2 (keyword CRUD), featured tags, followed hashtags (posts appear in home), markers, conversations, notifications with type exclusion, follow requests, blocks (federated `Block`/`Undo`), mutes with duration/expiry and `hide_notifications`, per-user domain blocks. OAuth2 with app registration, authorization code, client credentials and refresh_token flows, PKCE, consent screen, and scope enforcement (`read`/`write`/`admin:read`/`admin:write`). It talks fine to Elk, Tusky, Ivory, Phanpy, Semaphore and MastoBlaster.
**Streaming** - WebSocket and SSE. In-process pub/sub hub with per-connection send buffers, zero cost when no client is connected. Broadcast streams for public, local, remote, hashtags and lists. Per-account streams for user timeline, notifications and direct messages. Optional PostgreSQL `LISTEN`/`NOTIFY` backend for cross-process fan-out. Mastodon-compatible event serialization.
**Push notifications** - Full Web Push / VAPID (RFC 8030/8291) with `aes128gcm` encryption. Per-type alert toggles (mention, follow, reblog, favourite, poll, follow_request, status). Notify-bell support on followed accounts. Subscription expiry detection, rate-limit handling, 5-retry delivery.
**Media pipeline** - Upload processing: thumbnail generation (600x600), blurhash computation, EXIF stripping, magic-byte validation, SVG rejection, MIME mismatch detection, UUID-based file renaming. Size limits (40 MB default), pixel caps (16 MP default, tunable down to 4 MP for SBCs).
**Media privacy proxy** - This is the part I actually care about most. All remote media streams through the instance via HMAC-signed URLs (`/proxy/media?url=...&sig=...`), so local users never expose their IP address to remote servers. SSRF-guarded: DNS resolution check, private/CGNAT IP rejection, redirect re-validation. Pure `io.Copy` pass-through, no disk, no decode, ~32 KB buffer. Forwards HTTP `Range` requests for audio/video seeking. Configure a `proxy_secret` for stable URLs across restarts. On low-RAM devices, set `cache_remote = "off"` and you still see every image on the fediverse, the instance just doesn't store or process them.
**Remote media caching** - Three modes: `off`, `eager` (background sweep caches all remote attachments, avatars, headers and emoji, backfills existing on mode switch), `lazy` (cache on first access). Content-addressed, deduplicated by origin URL. Age-based pruning with file GC. Negative-cache for permanently dead URLs. Transparent origin fallback on cache miss. Open Graph preview cards stored durably with posts.
**S3-compatible storage** - A separate build tag (`-tags s3`), deliberately excluded from the default binary to keep it small. Supports AWS S3, MinIO, SeaweedFS, Ceph, Backblaze B2, Wasabi, DigitalOcean Spaces. Native media migration CLI: `littlefedi admin media storage-migrate` between local and S3 (DB-queue-backed, resumable, bounded batches). `storage-status`, `storage-cancel`, `storage-resume` commands. `storage-manifest` for rclone JSONL integration.
**Markdown posts** - Powered by goldmark with GFM extensions: tables, strikethrough, bare URL autolinking, hard wraps. Raw HTML deliberately not rendered. Output sanitized through bluemonday (defense-in-depth). Composer toggle in the web UI. Federates `source.mediaType: text/markdown` (Pleroma/GTS convention). Inbound Markdown source is rendered to HTML.
**Visibility modes** - The standard four (public, unlisted, private, direct) plus local-only (`local`, instance timeline only, never federates) and local unlisted (`local_unlisted`, followers only, no federation). Useful for notes to your own instance community.
**Bubble timeline** - Curated set of instances whose posts appear alongside local posts in a special timeline. Akkoma-compatible extension. Admin panel for adding/removing bubble instances. API endpoint at `/api/v1/timelines/bubble`.
**Moderation** - Account states: suspended (tombstone, federates `Delete(Person)`), silenced (visible to followers only, dropped from public timelines), quiet (like silenced plus it downgrades federation to followers-only, a middle ground I haven't seen anywhere else), disabled (cannot log in, content stays visible). Self-suspend prevention, last-admin-demotion guard. Blocks (bidirectional, federated), mutes (local-only, with duration and `hide_notifications`), per-user domain blocks (distinct from admin instance-wide blocks). Reports pipeline: user submissions plus inbound/forwarded `Flag` into an admin triage UI with resolution actions. Admin notification on new reports. Domain blocks with severity (`noop`/`silence`/`suspend`) plus Mastodon-parity options (`reject_media` enforced in the proxy, `reject_reports`, `obfuscate`, `public`). A moderation audit log records every admin action.
**Web UI** - Server-rendered HTML with `html/template`, templates embedded via `//go:embed`. Inline CSS (dark mode, Inter font, gradients). htmx 2.x and Alpine.js for progressive enhancement. No build step, no Webpack, no Tailwind, no npm. Every action works as a plain form POST without JavaScript. Works in Lynx, eLinks, text-only browsers, and on mobile.
Full feature set: home/public/local/bubble timelines with infinite scroll, profile pages with follow/unfollow/bell toggle, status threads with reply composer and background thread completion, post creation with CW, visibility selector (6 modes), media upload with alt text, Markdown toggle, quote posts (pre-loads composer with the quoted post as an inline card), post editing, composer autocomplete for `@mentions` and `#hashtags`, settings (display name, bio, password, sessions, moderation, pruning, account move, timeline preferences), report form, search page, tag management.
**Admin panel** - Dashboard (user counts, pending approvals, unreachable instances, open reports), accounts (with suspend/silence/quiet/disable/approve/reject actions), invites (CRUD), domain blocks (with severity and options), reports (triage and resolution), audit log, instance health (per-instance status with follower/following counts, reachability tracking, purge with typed-domain confirmation), bubble instances, settings, housekeeping (on-demand pruning), queue console (ready/scheduled/running/failed by job kind), media storage (S3 migration controls in S3 builds).
**Background jobs** - DB-backed queue that survives restarts, 8 job kinds: `inbox`, `delivery` (16 attempts over roughly 26h with capped exponential backoff and equal jitter), `push_notification`, `actor_refresh`, `poll_close`, `scheduled_status`, `media_cache`, `media_migration`. Per-instance circuit breaker suspends delivery at `backoff_count >= 10`. Actor refresh dispatcher with stale-while-revalidate, crash-safe leases, and per-actor exponential backoff.
**Backups** - Periodic or on-demand, server-side, no external tooling required. Each run produces a timestamped directory with `config.toml`, a portable database dump (`VACUUM INTO` for SQLite, `pg_dump` for PostgreSQL), an optional copy of owned media, and a manifest. Toggle it on, set an interval (`24h`, `7d`, whatever fits), decide whether to include owned media (the remote cache is always excluded, no point backing up other people's content), and set a retention count so old backups get pruned automatically. Off by default, one line to turn on.
**Housekeeping** - Automated pruning: remote statuses by age, own low-interaction statuses (per-user or server thresholds, min likes/boosts caps), tombstones, expired mutes, stale media (>24h unattached), orphaned media (deleted posts), unreferenced media files (disk files with no DB record), cached media by age, cache file GC. On-demand controls in the admin UI.
**Security** - Token-bucket rate limiting per IP. Security headers: `X-Content-Type-Options`, `X-Frame-Options`, `Referrer-Policy`, `Strict-Transport-Security`. Content-Security-Policy with nonce-based script/style. CORS. CSRF on all cookie-authenticated POSTs. Session fixation protection. Password reset token in a cookie, not the URL. OAuth consent screen (not auto-issuing). SSRF protection (DNS, IP and redirect re-validation) on all outbound HTTP. HTTP Signature algorithm enforcement (`rsa-sha256` only). Inbox body size limit (1 MB). Backfill goroutine cap. Thread-fetch amplification limits. File upload validation (magic bytes, SVG rejection, MIME mismatch). Username enumeration hardening.
**Operational** - Prometheus metrics at `/metrics` (counters for API/inbox/fed/web requests, statuses, deliveries, thread fetches, queue depth; gauges for workers, pending follows, uptime). Health checks (`/health`, `/readyz`). CLI: `admin create-user`, `admin set-admin`, `admin list-users`, `admin suspend/unsuspend`, `admin invite generate/list/revoke`, `admin media prune/prune-orphans/prune-files`, `admin media storage-migrate/status/cancel/resume/manifest`, `post` (publish from stdin/file with Markdown, visibility, CW, media, reply, quote), `migrate` (run migrations only). SMTP for password reset and notifications (falls back to stdout). Config via TOML file plus environment variables (`LITTLEFEDI_{SECTION}_{KEY}`).
**Platform support** - CGO-free, compiles with `CGO_ENABLED=0`. 23+ `GOOS/GOARCH` combos via the modernc SQLite driver: macOS (amd64, arm64), Linux (386, amd64, arm, arm64, loong64, ppc64le, riscv64, s390x), FreeBSD (386, amd64, arm, arm64), Windows (386, amd64, arm64), OpenBSD (amd64, arm64). NetBSD (amd64, arm, arm64) via a WASM-based fallback SQLite driver, I don't think anything else in the fediverse space explicitly targets NetBSD. PostgreSQL is a separate build tag (`-tags postgres`), S3 is another (`-tags s3`). The default binary carries neither, keeping it small. ARMv6 (GOARM=6) gets special treatment in the release naming, that's the Pi Zero target.
### Why it matters
The fediverse shouldn't demand a beefy VPS. It shouldn't require Docker, 2 GB of RAM, Redis, Sidekiq, or a JS toolchain that pulls in 800 packages. A 10 euro Raspberry Pi Zero W running NetBSD, sitting on a shelf, drawing less than 2 watts, can be a fully functional fediverse instance with a web UI, mobile app compatibility, streaming, push notifications, quote posts, account migration, and a moderation toolkit. That's not hypothetical, that's what this post is running on.
But don't mistake "runs on a Pi Zero" for "only runs on a Pi Zero". Point the same binary at real hardware and it scales to numbers that have nothing to do with hobby-instance territory. Low power is the floor, not the ceiling.
One binary, one config file, one SQLite database. Light, yet complete.
I've been involved in this project for a while now, though I can't say much more about it at the moment, there are other people involved besides me and it's not entirely my call to talk about it publicly yet.
#Fediverse #littleFedi #OwnYourData #NetBSD

2026-07-01 10:39:25 GMT

Ok, I'm testing something *cool*.
A blend of #snac, #Mastodon, #honk, #GoToSocial...and more.
This is running on a Raspberry PI Zero W, powered by NetBSD. The same that is powering my own smart thermostat. And it's quick.
I'll use this account and try to "stress" it.
Own your data. **Always** own your data!
#littleFedi #OwnYourData #Fediverse #NetBSD #RunBSD