We’re currently preparing #littleFedi for release under the #MIT license.
As part of that work, the GPL-licensed code previously included in the project has been removed or replaced. We’re now reviewing the repository to make sure the licensing information is clear and consistent throughout.
littleFedi works like a real app on your phone
A few people have asked me how to actually use littleFedi on mobile, so let's clear this up. I use MastoBlaster, for obvious reasons. But you don't need to build anything native - littleFedi is a Progressive Web App (PWA), and that means it behaves like a proper installed app once you set it up.
You add littleFedi to your home screen like any other app
It opens full screen, no browser address bar, no tabs cluttering things up
It works offline for the shell of the app, so a dead connection doesn't just throw a blank error page at you
You get real push notifications, even when the app isn't open
Static assets load instantly on repeat visits because they're cached on the device
Just your browser doing what browsers are supposed to do.
Installing it
On Android (Chrome or most Chromium-based browsers): open your instance, tap the menu, and choose "Add to Home screen" or "Install app". On iOS (Safari): tap the Share button, then "Add to Home Screen". That's it - the icon lands on your home screen and from then on littleFedi launches like a native app, in its own window, with its own icon and theme color.
Notifications that actually work
This is the part people are usually most surprised by. littleFedi uses Web Push, so once you enable notifications from the settings page, you get real-time alerts for mentions, boosts, favourites, quotes, follows, follow requests, polls ending, and a few other events - each with its own icon so you can tell at a glance what happened without opening the app. Tap a notification and it takes you straight to the right place, or focuses the app if it's already open in another tab.
This works the same whether the app is in the foreground, in the background, or fully closed. The browser's service worker handles delivery even when littleFedi itself isn't running.
Why it feels fast
Static files - the JavaScript, the icons, the stylesheets - get cached on your device the first time you load the app. On every visit after that, they load instantly from local storage instead of going over the network again, and the cache quietly checks for updates in the background so you're never stuck on stale code. Your actual content - posts, notifications, everything tied to your session - always comes fresh from the server, since that's the stuff that has to be accurate and can't be cached.
If your connection drops entirely, you'll see an offline page instead of a browser error, so it's clear what's going on rather than looking broken.
No extra app needed
If you're on mobile and haven't installed littleFedi yet, this is really the way to use it day to day. It's lighter than many native apps, updates itself automatically, and you're not waiting on anyone to approve a release in an app store. Just add it to your home screen and it stays there, working like any other app on your phone.
threw in a fedicat platform definition for #LittleFedi, looking good, can’t wait to check out the source!
Hello from the other side!
Yes, it's true. This instance is now running from the Orange PI PC (NetBSD, armv7). It's currently using the SD Card. The performance is...you judge! And it's not set to low_power mode!
EDIT: we're back to the VPS for now.
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: 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.09CPU states: 0.0% user, 0.0% nice, 0.0% system, 1.0% interrupt, 99.0% idleMemory: 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!
This is the mobile web interface of #littleFedi. It can also be installed as a PWA, with push notifications.
littleFedi allows you to hide all posts that have images without alt text.
Because yes, that's how it should be.
Well, this is happening. 😃
For the first time, littleFedi is going to meet the public.
Berlin FediDay, Raspberry Pi Zero 2 W, pre-release build.
Please be gentle with it.
Or don't. That's part of the test. 😄
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
another great addition to #littlefedi is relay subscribtions and emoji picker 😘
Hi everyone, I'm Stefano
Also known as the BSD Cafe and illumos Cafe barista - @stefano and @stefano@illumos.cafe
This is the first post from littleOne (littleone.littlefedi.social), the first littleFedi instance open to outside users.
littleFedi is a new ActivityPub server, still in active development, written in Go and shipped as a single binary. It speaks standard ActivityPub, so it federates normally with Mastodon, snac, GoToSocial, Akkoma and the rest of the fediverse, and it exposes a Mastodon-compatible API, so most existing apps already work with it.
A few things about it that aren't the usual fediverse defaults:
Catch-up instead of an algorithm. Timelines stay chronological, full stop. There's a separate /catchup page, visited on demand, that ranks what you missed using only signals this instance already has locally - who you follow boosted it, replies and favourites delivered here, hashtags you follow. No external popularity data comes in, nothing about what you read is tracked. It answers "what did I miss" without turning into a feed that decides for you.
Static blogging built in. Any post can be marked as a blog post and gets published as a plain static page under /@username/blog/, with its own permalink, Atom feed, and no JavaScript or database hit per view, while still being a normal federated post underneath. A proper home for longer writing that doesn't need to compete with a timeline.
Self-expiring posts. Any post can be given a timer and auto-delete on its own.
Bubble timeline. A middle ground between local and federated: a timeline scoped to a set of instances you've chosen to group together, not just your own or everything.
littleMesh. A way to federate without a public domain, certificate, or open port at all - meant for something like a Raspberry Pi behind NAT. Instances get an address derived from an Ed25519 key pair and reach each other through pinned relays that never see plaintext.
No trends, no suggestions. These are intentionally left empty. Nothing here is trying to surface "popular" content or keep anyone scrolling longer.
Security defaults taken seriously. Signed federation (HTTP Signatures), optional Object Integrity Proofs, TOTP MFA, audit logs, and full account export, migration and deletion if you ever want your data to live somewhere else.
This instance is here to test all of that with real accounts, not just a small group ones'. In the next few days I'll be reaching out to everyone who already told me they were interested, to set the first accounts up - an invite is coming. If you'd rather just follow along and see how it goes, that works too.
It's a test instance, so expect the occasional rough edge. If something breaks or feels wrong, tell me - that's exactly what this phase is for.
Hej, I'm Florian, or Flo for short (only my family calls me with my full name).
Born 1977 as a gay person, and raised near Lake Constance in the south of Germany.
After my parents got a divorce and my father met another woman, we moved to Dresden, when I was 15.
Lived here until I started my apprenticeship in 2000 in Lindau (Lake Constance), so moved back again.
After being self-employed (ebay seller and creating simple websites), which unfortunately wasn't sustainable, I took a job in the security branch, however only got contracts for one year (three times), until I moved back to Dresden in 2010 and lived here ever since.
Since 2018 I have a dog, which you can see in my header picture, when we took a walk along the river Elbe.
Currently unemployed (since May '24), IT-support (thanks "AI", which overtook my profession, I guess).
Interested in too many things, like minimalism, barefoot shoes, cycling, music, interior design, and much more.
Edit: I love languages, especially constructed ones, like Esperanto, Lingwa de Planeta, Mini Linga, started to learn Swedish, Italian, Welsh, however didn't stick to neither of them.
I was a twitter "power user", from 2009-2022.
Created my first account in the fediverse on mastodon.social in 2018, however only used it sporadically.
Since the end of 2022, I exclusively use the fediverse and experienced different network software (mastodon, akkoma, pixelfed, and now littlefedi).
That's it as an introduction for now 😀
PS: English is my first foreign language, so please bear with me in case of errors.
The Blog Option in littleFedi
...and yes, this is build and served by the Raspberry Pi Zero W, powered by NetBSD
https://rpi0w.stefanomarinelli.it/@stefano/blog/691cb62e-e7a1-434b-ba65-d059ee58ac41/
RE: https://rpi0w.stefanomarinelli.it/@stefano/6e542287-1d97-49a1-8b3d-1801854aa8a4
Honestly, I’m really excited about this!
littleFedi: a Fediverse Server That Doesn't Need a Data Centre
I was fifteen, and there were no BBSes in my city. So every call was long distance, once a day, sometimes twice. I'd start the dialer and wait for that sound - the handshake, the negotiation, the hiss settling into a carrier - and then I was connected to a computer sitting in somebody's bedroom, a few hundred kilometres away. I was a co-sysop of a local board and a national moderator of a FidoNet area. None of my friends understood what I was doing, and they'd stopped asking to avoid an incomprehensible monologue. But I liked it, and that was enough for me.
Here's the thing about that computer in someone's bedroom. There was no data centre. No domain, no certificate authority, no hosting provider, no cloud. Just a machine, a phone line, and a person who'd decided to run it. If you wanted to reach it, you called it.
Now look at what it takes today to put a small server on the network so other people can talk to it. A public address, which most home connections no longer have. A domain, which you rent. A certificate, which somebody has to issue you. And, increasingly, a VPS somewhere, because the software won't fit on the hardware you already own.
We've added a lot of infrastructure between two people who just want to talk. That's what littleFedi is about.
What it is
A single Go binary. No Ruby, no Sidekiq, no Redis, no separate worker processes to babysit. You run init, answer a few questions, and you've got a working instance. It speaks ActivityPub, and it speaks the Mastodon client API well enough that existing apps just work.
It also runs on hardware that would make Mastodon - or even Akkoma - struggle. Most software in this space assumes a VPS with a few gigabytes of RAM and a database server next to it. We assumed a Raspberry Pi Zero W behind a home router. There's a low_power mode that tunes memory use, image decoding and thumbnail generation for exactly that kind of box, and it's tested on that kind of box, not just on a fast dev machine.
In spirit this puts littleFedi close to snac, which I've always liked a lot. Same conviction: a personal server shouldn't need a fleet of services behind it.
Federating without a public address
littleMesh is the part I'm most attached to, and it's the part that goes back to the modem.
Your instance generates an Ed25519 key pair. That key is its identity - the node's address is derived from the public key, so reaching that address means reaching the holder of that key and nobody else. No registrar, no certificate authority, nobody to ask permission from.
A small set of public lighthouse nodes help two instances find each other. Once they're introduced, the traffic runs over a second TLS session pinned to both node IDs. The lighthouse copies encrypted bytes back and forth. It never sees plaintext, and it can't impersonate either side. And if the two nodes can reach each other directly, they drop the relay after the introduction and talk peer to peer.
Which is, more or less, calling the BBS directly. Just without the phone bill.
The gateway into ordinary HTTPS
Mastodon and other regular servers can't resolve a mesh address on their own. There's no domain and no certificate for them to find.
That's what the optional HTTPS gateway is for. A lighthouse operator can run one alongside the relay, and it bridges the mesh into ordinary HTTPS for the rest of the web. The gateway has to terminate TLS to do that, so it can technically see the traffic passing through it. Which is exactly why it's a separate, opt-in piece and not something every node exposes by default.
It has two independent settings: one controls what the gateway lets ordinary internet visitors reach at all, and a second one applies again at the destination node. Left at their defaults, both allow only federation traffic - ActivityPub delivery, discovery, public media. Web login, API and media proxy stay closed unless an operator deliberately opens them.
Mesh peers talking to each other directly never touch the gateway at all. That exposure only applies to the bridge into the wider web. And all of this can be self-hosted.
Chronological timelines
Timelines are chronological. Nothing gets reordered by an engagement model.
If you want something closer to "what did I miss", there's a separate /catchup page you visit on purpose. It ranks posts using signals your own instance already has - how many people you follow boosted something, whether it continues a conversation you took part in. No external popularity score, no telemetry, nothing leaves the machine. You press "mark as read", it moves a divider, and that's the only thing it remembers.
Self-expiring posts
You can set a post to expire, with its own timer, instead of a fixed instance-wide setting.
This isn't a client-side trick that hides the post from view. The expiry goes on the same durable job queue that runs the rest of littleFedi's background work, so the deletion survives restarts and isn't lost if the process happens to be down at the moment the timer fires. When it does fire, the post is deleted and a real Delete activity goes out to everyone who received it - so it actually disappears from remote instances too, not just locally. Editing the post before then can push the timer back or cancel it.
Static blogs, with real threaded replies
littleFedi can take a Fediverse post and publish it as a page on a plain static blog, with its own Atom feed and permalinks that don't move even if you edit the post later. No JavaScript, no database hit on page load.
The part I find more interesting is that the replies aren't left out. If the author turns the option on, littleFedi pulls the public replies that were actually federated to the post, threads them the same way the timeline does, and bakes the whole tree into the generated HTML at build time. So a blog post can show a real comment thread, in the same static file, with the same guarantee as the rest of the page - no JavaScript, no live queries. Only public and unlisted replies qualify, obviously. Anything followers-only or direct never enters the picture.
Why it looks like this
This isn't minimalism for its own sake. It's about how many people simply can't run their own server today, because the requirements are too steep. The hardware, the ops complexity, or just needing a domain and a public address before you can start. We're trying to remove those barriers one at a time, while still shipping a real, federating, reasonably complete server: polls, quotes, scheduled posts, MFA, PostgreSQL and S3 if you want to scale up later.
I've written before about taking a semi-truck to buy salad. Hardware keeps getting more expensive and the software running on it keeps asking for more of it every year. That's backwards. If the machines cost more, the operational cost of what sits on them should go down, not up. Same with complexity: the default direction is to keep adding it, and we'd rather strip it out.
And there's the other half, which is closer to why any of us are doing this at all. It's the same thing that drew me to snac and to the way grunfink works on it, and the same thing that had me dialing a stranger's computer at fifteen. People building tools so that people can talk to each other. Nothing more dressed up than that. We'd rather show the servers running, talk about the Pi sitting in the corner, share a tiramisu photo if it comes up. The joy in this was never about the money it brings in. It's about what we end up building, humanly, because of it.
It's beta software, still short of a first release, and I'd rather say that plainly than oversell it. But it runs, and it federates. That's the part I wanted to write about.
Another step closer to release!
The official website is now live at https://littlefedi.org/ with documentation and project details.
Take a look and let me know what you think!
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.
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.
Do you want to chat about littleFedi on Matrix?
We have a space, we have a room!
Join us at https://matrix.to/#/#littlefedi-general:bsd.cafe
See you there!
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! 🚀
