Stefano on littleFedi
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!
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 401 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.
EDIT: littleFedi allows to transform posts into blog posts, having its own SSG (Static Site Generator). The one generated by this post is reachable by clicking here.
1
1
๐ฅ 2
1
โค๏ธ 1
โค 5
1
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.
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!
@berlinfediday @grunfink @prahou look, the snac lightning talk is online. But I am sorry that it's in german. I was too nervous to have it in english this time ๐ But when there is a good opportunity to give that talk again, it will be in english then :)
You go shopping andโฆ
In todayโs episode of "You canโt pronounce the hostname but you can hopefully read the content", an overview of the two #ThinkCentre that I recently got, centered towards power consumption when running #FreeBSD, #NetBSD and #OpenBSD.
TL;DR:
not bad at all!
https://www.tumfatig.net/2026/what-about-thinkcentre-m710q-m720q-and-bsd/
For some (many?) years, Iโve embraced a philosophy: defuse.
When a situation is going nowhere and the tone starts heating up, the best thing to do is to defuse. Going on would only make things worse, with the risk of saying something I might regret later.
Is it right? Not always. Is it wise? Most of the time, yes.
Will I regret it? No, I donโt think so.
Sometimes itโs better to stop arguing, take note, and act accordingly.
We're getting there...
@littlefedi_official@littleone.littlefedi.social
How littleFedi will be released
The release of littleFedi is scheduled for 1 October 2026.
The release will happen in phases but, from the very first day, it will be possible to use the software in its entirety. Tests and complete documentation are still under heavy revision and will not be ready by then, but we do not want to postpone the release any further.
The code has already been reviewed by several people, who gave us feedback and suggestions I cared a lot about. I want to thank everyone who did it. You know who you are.
There will probably be many bugs because, and this also came out during the reviews, although I already knew it, the quality of the code is not uniform yet.
littleFedi was created by different people, at different times, working on different components and with different levels of experience. And it shows: some parts of the code are of good quality. Others are not.
The reviews of the last few months tried to make things more consistent, but clearly this is not an easy task. In the end, what matters to me is not that the code is beautiful, but that it is sufficiently lean and secure.
So far, the reviews performed have not found security problems serious enough to block the release. Everything else can be fixed along the way.
For the moment, distribution will not happen through BSD Cafe Brew, our Forgejo instance, but directly from the littleFedi website:
You will be able to download a source tarball, or latest, which will simply point to the same tarball. Inside the binaries directory there will also be around 180 precompiled builds for the different platforms and all the possible feature combinations, for example PostgreSQL + S3.
Blog support will be included in all precompiled builds.
Of course, those binaries have not been tested on every single platform. I do not have an AIX/ppc64 machine available, let alone a Windows machine.
But they compile, and at this stage that is enough for me.
For the moment, there will not be fixed releases.
New builds and source releases will be published whenever appropriate, distributed in the same way. The goal is to eventually publish everything on BSD Cafe Brew, our Forgejo instance, but this will happen when tests, complete documentation and the rest are ready too. In practice, at this stage the team prefers to keep more direct control over releases and the management of code, patches and so on.
The license is still MIT, so there is maximum freedom to use and modify the software. This is simply what the team has chosen for now.
The official announcement account will be this one, hosted on the littleOne instance:
@littlefedi_official@littleone.littlefedi.social
https://littleone.littlefedi.social/@littlefedi_official
littleOne will remain online as a test instance. I would not really call it the "official" littleFedi instance, but almost. In the future we may create a larger instance using PostgreSQL, S3 and so on. But this is not really the purpose of littleFedi.
littleFedi is about decentralisation and control over your own data. In an ideal world, everyone would have their own Fediverse software, their own instance, different levels of federation, like Bubbles, which still need some refinement in littleFedi, and allowlists and/or blocklists.
For now, this is just a small step in that direction, adding another alternative to already excellent software such as Mastodon, snac, GoToSocial, Akkoma, Mitra and others.
1 October is close, and the release will be accompanied by a post containing some background information and details that have never been revealed before.
Those details will also help explain some of the technical choices behind the software itself, and why I am the one presenting it to the world. I have not decided yet whether I will publish it here or on my IT Notes blog, but it will definitely be announced.
We are almost there.
It has been a long journey to reach this point, and the best part has not even started yet.
Fasten your seat belts, we are ready to go again!
How littleFedi will be released
The release of littleFedi is scheduled for 1 October 2026.
The release will happen in phases but, from the very first day, it will be possible to use the software in its entirety. Tests and complete documentation are still under heavy revision and will not be ready by then, but we do not want to postpone the release any further.
The code has already been reviewed by several people, who gave us feedback and suggestions I cared a lot about. I want to thank everyone who did it. You know who you are.
There will probably be many bugs because, and this also came out during the reviews, although I already knew it, the quality of the code is not uniform yet.
littleFedi was created by different people, at different times, working on different components and with different levels of experience. And it shows: some parts of the code are of good quality. Others are not.
The reviews of the last few months tried to make things more consistent, but clearly this is not an easy task. In the end, what matters to me is not that the code is beautiful, but that it is sufficiently lean and secure.
So far, the reviews performed have not found security problems serious enough to block the release. Everything else can be fixed along the way.
For the moment, distribution will not happen through BSD Cafe Brew, our Forgejo instance, but directly from the littleFedi website:
You will be able to download a source tarball, or latest, which will simply point to the same tarball. Inside the binaries directory there will also be around 180 precompiled builds for the different platforms and all the possible feature combinations, for example PostgreSQL + S3.
Blog support will be included in all precompiled builds.
Of course, those binaries have not been tested on every single platform. I do not have an AIX/ppc64 machine available, let alone a Windows machine.
But they compile, and at this stage that is enough for me.
For the moment, there will not be fixed releases.
New builds and source releases will be published whenever appropriate, distributed in the same way. The goal is to eventually publish everything on BSD Cafe Brew, our Forgejo instance, but this will happen when tests, complete documentation and the rest are ready too. In practice, at this stage the team prefers to keep more direct control over releases and the management of code, patches and so on.
The license is still MIT, so there is maximum freedom to use and modify the software. This is simply what the team has chosen for now.
The official announcement account will be this one, hosted on the littleOne instance:
@littlefedi_official@littleone.littlefedi.social
https://littleone.littlefedi.social/@littlefedi_official
littleOne will remain online as a test instance. I would not really call it the "official" littleFedi instance, but almost. In the future we may create a larger instance using PostgreSQL, S3 and so on. But this is not really the purpose of littleFedi.
littleFedi is about decentralisation and control over your own data. In an ideal world, everyone would have their own Fediverse software, their own instance, different levels of federation, like Bubbles, which still need some refinement in littleFedi, and allowlists and/or blocklists.
For now, this is just a small step in that direction, adding another alternative to already excellent software such as Mastodon, snac, GoToSocial, Akkoma, Mitra and others.
1 October is close, and the release will be accompanied by a post containing some background information and details that have never been revealed before.
Those details will also help explain some of the technical choices behind the software itself, and why I am the one presenting it to the world. I have not decided yet whether I will publish it here or on my IT Notes blog, but it will definitely be announced.
We are almost there.
It has been a long journey to reach this point, and the best part has not even started yet.
Fasten your seat belts, we are ready to go again!
SmartOS: The illumos Way of Thinking About Servers
A practical look at SmartOS, illumos, zones, LX compatibility and the way this operating system approaches servers. Not a complete guide, just enough to understand why I like it.
https://it-notes.dragas.net/2026/09/28/smartos-the-illumos-way-of-thinking-about-servers/
#SmartOS #illumos #Hosting #Server #IT #SysAdmin #OwnYourData #ITNotes #Tutorial
We are pleased to announce the BSDCan 2027 dates and location:
Tutorials: July 7-8, 2027 (Wed & Thurs)
Conference: July 9-10, 2027 (Fri & Sat)
Location: Vancouver, Canada
This is one of the reasons why #littleFedi exists...
I like Mastodon, I really do. But it has so, so many dependencies, and updating it on illumos or OpenBSD is getting really difficult, release after release.
Some dependencies are primarily distributed as binaries, or only build on Linux and macOS. It's not Mastodon's fault, but it depends on them.
Thatโs why, in my opinion, solutions like snac, GoToSocial, or littleFedi have a reason to exist: all of this is much, much easier...
#Fediverse #snac #GoToSocial #littleFedi #OwnYourData #Mastodon
This is a modern motherfucking website.
And itโs still fucking perfect.
Hey! Hello cricket!
As promised, the littleFedi source code will become publicly available in about a week.
We will publish a snapshot of the complete source tree, together with some basic instructions to build and run it. Pre-built binaries will also be provided.
This will not yet be a proper littleFedi release. Documentation still needs work, testing needs to be expanded, and several things need to be cleaned up before we can call it that.
But the important part is that the code will finally be out there.
People will be able to read it, build it, experiment with it, start using littleFedi..
Over time, development will progressively move to the BSD Cafe Forgejo, where we will have the usual tools for issues, contributions, releases and collaborative development.
We're not quite there yet.
For now, the first step is simple: open the doors and let people get their hands on the code.
About one more week.
@nelfan@gotosocial.social littleFedi is light on the hardware resources. A small VPS can host a lot of users, it doesn't require much power.
Yes, the BSD Cafe has been upgraded. But this is a test, as Mastodon changed some of the quote post behaviour in 4.7.x and I'm trying to see if littleFedi is still able to manage it ๐
Oh, hello, cricket! I was starting to be worried!
This is a periodic reminder that this instance is running littleFedi on a Raspberry PI Zero W powered by NetBSD
@jm@snac.jmjanzen.dev yes, some people can be... (well, I don't want to complete the sentence here ๐)