Stefano Marinelli - littleFedi

https://littleone.littlefedi.social/@stefano

Barista at BSD Cafe and illumos Cafe - Stefano Marinelli (npub1ef5…gcpc) / Stefano Marinelli (npub1gac…4w3w)

Spreading weather forecasts all over the Fediverse via [FediMeteo](https://fedimeteo.com ) - FediMeteo (npub1qcy…8kt9)

Testing littleFedi here on littleOne, its first instance open to outside users. Small ActivityPub server, single Go binary, still in active development.

I will also use this account to provide information about this instance and the development of littleFedi.

#littleFedi #Fediverse #OwnYourData

Public Key

npub1pn5kp8lxccavveesvl9yyapuuhkk2rr5uu7sfz9zhfqvxjw70fwsea4tzd

NIP-05 Address

stefano_at_littleone.littlefedi.social@momostr.pink

Profile Code

nprofile1qqsqe6tqnlnvvwkxvucx0jjzws7wtmt9p36ww0gy3z3t5sxrf8085hgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds5j8ge9

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1pn5kp8lxccavveesvl9yyapuuhkk2rr5uu7sfz9zhfqvxjw70fwsea4tzd

Show more details

Last Notes

2026-09-07 18:24:50 UTC

Hello, littleFedi friends!
Some days ago, I created an official account for the littleFedi project. It's still almost empty and I'm planning to populate and starting to post from it after EuroBSDCon.
If you want to receive the official communications about littleFedi, you can already follow that user: @littlefedi_official
Enjoy!
#littleFedi #littleOne

2026-09-07 15:44:10 UTC

# For the first time, littleFedi will be shown publicly
And I have to say, this makes me very happy. :)
A pre-release build will be running on a **Raspberry Pi Zero 2 W** at **Berlin FediDay**, where people will be able to see it, try it, play with it, and probably abuse it a little too.
Unfortunately I won't be there in person, because I'll be at **EuroBSDCon** that same weekend.
But really, what better place than FediDay for the first public appearance of littleFedi?
A huge thanks to @npub1xpz…a80p - Adam - for taking this on, building the demo, testing it independently, and agreeing to respect the temporary source embargo while we complete the last checks before the public release.
I'm especially curious to see how littleFedi behaves once it's in the hands of people who didn't build it.
This is exactly the kind of test I was hoping for.
More details about the presentation:
https://ctalx.c-base.org/fediday-2026/talk/review/AJNLVMPYRSVX3JDHDHYSEZZNSP9KQSYH
#littleFedi #littleOne #OwnYourData #Fediverse

2026-09-05 07:21:06 UTC

**A small development update from the last two days:**
- We added a couple of quality-of-life options for the web interface. You can now choose whether your timeline and notifications refresh automatically as new activity arrives. The preference is saved in your browser, so it remains in place between visits.
- There is also a new option to choose your default landing page. If Catch-up is enabled on the instance, you can make it the page you see when opening littleOne, rather than always starting from the home timeline.
- We also revised relationship notifications. Notifications for unfollows, blocks, unblocks, and rejected follow requests are now disabled by default. They can still be enabled individually from **Settings → Notifications** for people who want them.
- Instance administrators can additionally disable those notifications for everyone through the configuration file:
```
[instance]
block_sensitive_relationship_notifications = true
```
When this option is enabled, the personal setting is hidden and individual opt-ins are overridden. Existing notifications and saved preferences are left untouched.
- Alongside these changes, we merged a few branches and reviewed several incoming requests.
Thanks to everyone who contributed feedback and testing!
#littleOne #littleFedi
```
```

2026-09-03 19:17:59 UTC

# Today’s littleFedi updates:
- Strengthened allowlist-only federation: redirects, discovery, deliveries, and hostname handling now consistently respect the policy. (**Spoiler alert:** there's a reason behind this 😉)
- Fixed boosts for local-only posts, plus a timeline relative-time refresh issue.
- Fixed an Android PWA green-bar issue by letting the manifest update normally.
- Disabling remote media caching now safely clears leftover cache jobs instead of leaving the queue unhealthy.
#littleFedi #littleOne #Fediverse #OwnYourData

2026-09-03 07:49:26 UTC

There are **48 local accounts** on this instance.
It may not be extremely active, but *SQLite is handling the workload very well*. The load is currently close to zero, even though littleFedi is running on a cheap VPS with 2 cores and 4 GB of RAM. It handles federation, lazy media caching, housekeeping and the usual background work
while using around **600 MB of RSS**.
That figure represents the whole process footprint - not just the post cache - and includes the Go heap, reusable allocations, buffers and SQLite memory mappings.
When an incoming post is relevant to a local user, littleFedi inserts it into that user’s materialized home feed in SQLite at ingest time. Opening the home timeline therefore requires an indexed read instead of rebuilding it from follows and followed hashtags. A bounded in-memory cache also keeps hot entities, timeline windows and rendered pages ready, while a background warmer refreshes the timelines of recently active users.
Cache misses, restarts and evictions still fall back to SQLite, but the normal warm path is very fast. The bubble timeline also uses the cache, although its cold database path still needs quite a bit of work.
For comparison, **my single-user instance on a Raspberry Pi Zero 2 W uses around 60 MB of RSS a few seconds after browsing around**.
Go’s garbage collector runs automatically and reclaims unreachable heap objects. Some memory may remain reserved for reuse, however, so RSS does not necessarily fall immediately after a collection cycle.
littleFedi isn’t trying to compete with snac on minimalism - snac is awesome and remains the best solution for many scenarios. The goal is to offer a different experience while remaining usable across a wide range of hardware platforms and operating systems.
#littleFedi #littleOne #OwnYourData

2026-08-31 06:58:03 UTC

There was a problem and users following a #littleFedi instance from an #Akkoma instance were left in a pending situation.
It should be fixed now. Thank you @npub1qf5…ynp2 and @npub12wp…e8ay for your help!

2026-08-30 10:31:06 UTC

Go, #littleFedi, go!
#littleFedi #littleOne
#note1e4s…39tr

2026-08-28 13:28:07 UTC

**littleFedi doesn't need a Raspberry PI to run.**
It *can* run on a Raspberry PI - and this is totally different.
It's a *Go* app, so the current compatibility matrix is:
| Operating system | Published binaries (`make release`) | Full release matrix (`make release-all`) | Also compiles (`make allreleases`) |
| ----------------- | ----------------------------------- | ---------------------------------------- | ------------------------------------- |
| **FreeBSD** | amd64, arm64 | 386, arm | none |
| **Linux** | amd64, arm64, arm | 386, loong64, ppc64le, riscv64, s390x | mips, mipsle, mips64, mips64le, ppc64 |
| **NetBSD** | amd64, arm | arm64 | 386 |
| **OpenBSD** | amd64, arm64 | none | 386, arm, ppc64, riscv64 |
| **illumos** | amd64 | none | none |
| **macOS** | amd64, arm64 | none | none |
| **Windows** | amd64 | 386, arm64 | none |
| **Solaris** | none | none | amd64 |
| **DragonFly BSD** | none | none | amd64 |
| **AIX** | none | none | ppc64 |
| **Plan 9** | none | none | 386, amd64, arm |
| **Android** | none | none | arm64 |
#littleFedi #littleOne

2026-08-28 13:04:08 UTC

littleOne is a **powerful** (!!!) 2 core, shared VPS, with 4 GB Ram.
It's almost idle.
But the Raspberry PI Zero W powered by NetBSD is a good testbed. Not because you *need* it, but because you can. And if it runs there... 😉
#littleOne #littleFedi
#note1g60…enp8

2026-08-27 19:40:56 UTC

This is the *"roost"* littleFedi theme
#littleFedi #Fediverse
https://littleone.littlefedi.social/media/01a044bd-5751-7ab6-9814-bd4de7da8b3a/image.png

2026-08-25 13:42:50 UTC

littleFedi allows you to hide all posts that have images without alt text.
Because **yes, that's how it should be**.
#littleFedi #littleOne #Fediverse
https://littleone.littlefedi.social/media/01a03928-cc77-7c7d-8de5-019ece29a358/image.png

2026-08-25 13:00:37 UTC

The plan was to release the source code for #littleFedi before the end of the month, but #EuroBSDCon takes place shortly after and I'll be quite busy.
Since the first few days post-release are always the most dynamic, the plan now is to release it right after (*shortly after 15 September*), allowing a few more weeks for bug fixes, tweaks, integrations, etc., that the **wonderful** people on this instance are sending in day after day.
**To all of you: thank you!**
#littleFedi #littleOne

2026-08-24 19:10:52 UTC

A little while ago I wondered: how many people are on this server?
The answer was, of course, obvious.
**42.**
Douglas Adams was right all along.
#littleOne
https://littleone.littlefedi.social/media/01a0352e-c58d-7334-8f0b-c145c5d2046a/image.png

2026-08-22 07:50:22 UTC

Do you want to chat about littleFedi on **Matrix**?
We have a space, we have a room!
Join us at https://matrix.to/#/!aAoNhGCROAnRqmlWCo:bsd.cafe?via=bsd.cafe
See you there!
#littleFedi #littleOne #Matrix

2026-08-22 07:10:15 UTC

- reply

not yet, but this is a good idea. I'll create one later today. Thanks for the idea!

2026-08-20 17:10:21 UTC

# littleFedi and your data
Several people have asked me the same thing over the past few days, in different words but with the same question underneath: "if I set up a littleFedi instance, or open an account on one that is already running, what ends up stored somewhere?".
It is a fair question and it deserves a precise answer. So I went back and reread the code, the database schema and the default configuration, and what follows is what I found. Including the parts I do not like, and the parts no fediverse software can solve.
One premise that applies to everything else: littleFedi is a binary running on a server. Whoever administers that server has access to the database. This is true for littleFedi, for Mastodon, for snac, for GoToSocial, for anything. The difference is how much that database holds, and how much of it leaves for the outside world without anyone asking.
The database holds the obvious things: username, display name, bio, avatar, header image, the key pair that is the account's ActivityPub identity, posts, favourites, follows, blocks, mutes, bookmarks, lists, filters.
Then the preferences: theme, interface language, default post language, default visibility, which notifications you want by email, which by push. Functional stuff.
Email is optional. `require_email` is `false` by default: on a single-user instance you can leave it out entirely, and on a multi-user one it is the operator who decides whether to require it. If you do provide it, it is used for verification, password reset and the notifications you chose. Nothing else.
The password is hashed with bcrypt. The TOTP secret, if you enable the second factor, is encrypted at rest, not stored in the clear.
And here is something I want to say because it was a deliberate choice: **every bearer token is stored as a SHA-256 hash, never in the clear.** Session tokens, OAuth access and refresh tokens, application client secrets, password reset tokens, email verification tokens. Anyone who walks off with a copy of the database does not walk off with reusable credentials.
We did a cleanup on exactly this just yesterday. The sessions table had been carrying a legacy `token` compatibility column for a long time, inherited from an older schema. It held nothing dangerous, because the function that creates sessions was writing the hash into it rather than the browser token, and I checked that this is the only path that leads to an insert. But the guarantee lived in one line of Go, not in the schema. A line of Go can be removed by accident; a column that does not exist cannot. So I dropped the column with a migration, and now there is simply nowhere in the `sessions` table for a token in the clear to end up.
*There is exactly one place where an IP address ends up*
The `sessions` table. When you log in, littleFedi saves the session row with: hashed token, creation date, expiry, User-Agent and IP address.
It serves one purpose: the **Settings > Sessions** page, where you can see your active logins and revoke them one at a time. It is your data, shown to you. There is no admin screen listing users' IP addresses, and we did not write one on purpose.
Sessions last 30 days and are removed by automatic maintenance when they expire, along with the push subscriptions attached to them.
What is **not** saved, and what other software does save:
- **No registration IP.** Until yesterday the registration struct had a field for the IP and one for the User-Agent that nobody ever read: the data arrived inside the function and died there, without touching the database. We took them out. I did ask myself whether it was worth actually recording it, the way Mastodon does, and the answer I arrived at is no. There is really only one use case, the wave of fake accounts created in bulk, and in that case you already have the data: a freshly registered account that is spamming has an open session, and that session holds the IP and the User-Agent. Someone who registers and never logs in is not spamming. On top of that the IP is a weak signal in itself, between CGNAT, mobile carriers and VPNs, while invites, manual approval and email verification are real defences. And unlike the session, which expires in 30 days and disappears, a column like that would stay attached to the account forever: one more entry in the privacy policy, one more target in a breach, and one more thing someone can come asking for with a stamped piece of paper. On a single-user instance it would mean nothing at all.
- **No last-login IP** on the account. Only the session, which expires.
- **No IP history.** Close the session and that row is gone.
- The per-IP rate limiter does exist, but it keeps its counters **in memory only** and cleans them up by itself. It never touches the disk.
What about cookies?
*Five*, all first-party, all functional:
`session` (HttpOnly, SameSite=Lax, Secure when you are behind HTTPS, 30 days), `pwreset_token` (lives 15 minutes during a password reset), `locale`, `theme`, `appearance`.
There is nothing else. There is no analytics cookie because there is no analytics.
**Zero third parties**
What the code does not contain: Google Analytics, Matomo, Plausible, Sentry, a CDN, a remote font, a third-party script, a pixel, a beacon. And, old-fashioned as it may sound, there is no AI listening in and offering suggestions.
The default Content-Security-Policy is `default-src 'self'` with a nonce for inline content. Pages load only what your own instance serves. If someone tried to slip an external resource in tomorrow, the browser would block it on its own.
There is not even an update check phoning home. littleFedi does not know you exist and I have no way of finding out.
The only connection to a server of mine is the commercial Big Tech domain list, still empty, (`https://littlefedi.org/lists/commercial-bigtech.csv`), which is downloaded **only if you turn that block on**, and it is off by default. It is a download of a CSV of domain names: it sends nothing about you, and you can point the same option at your own list or at a mirror.
The `/metrics` endpoint is disabled by default.
What about logs?
Here I owe you the whole truth. The access log is **on** by default and writes one line per request: method, path, status, bytes, duration and remote address.
High-volume, low-value requests (static assets, proxied media, `/health`, `/metrics`, `/robots.txt`, the service worker) are logged at debug level only, so at the default `info` level they stay silent. But pages are logged.
It goes away with one line:
```
[observability]
access_log = false
```
And retention is not littleFedi's call: those lines end up wherever your init system sends them, journald or syslog or anything else. It is the operator who decides how long they stay. In the policy template I ship I suggest 14 days as a starting point.
As for media?
EXIF metadata on uploaded images is **stripped by default** (`strip_exif = true`). Orientation is preserved because it is baked into the pixels before the rewrite, so the photo does not end up sideways.
With one honest caveat: the rewrite only happens for JPEG and PNG. GIFs are deliberately left untouched, because rewriting them would flatten the animation, and WebP files are not rewritten because the library I use has no WebP encoder. In practice: if you upload a WebP with GPS coordinates inside, those coordinates stay. I am saying it plainly because it is better to know than to find out. We will look at it later on.
File names are randomised (`rename_media = true`), so `IMG_20250812_my_coffee.jpg` does not become a public URL.
And then there is the thing I am proudest of, which is on by default: **the remote media proxy.**
`proxy_remote = true`. When an image, an avatar or an emoji living on another server shows up in your timeline, your browser does **not** contact that server. It contacts your instance, which streams it through. The result is that the remote instance does not see your IP address, does not see your User-Agent, does not see what time you read that post, and cannot use an image as a tracking pixel.
Proxy URLs are HMAC-signed and regenerated on every response, never stored anywhere. And `cache_remote` is `off` by default: the stream is passed through and that is it, without keeping other people's media on your disk. If you would rather keep them to cut down on traffic there are the `lazy` and `eager` modes, but that is your choice, not a default you find yourself saddled with.
I will add the security headers, which are privacy too: `X-Frame-Options: DENY`, `X-Content-Type-Options: nosniff`, `Referrer-Policy: strict-origin-when-cross-origin` (meaning: when you click a link to the outside, the destination site does not see which exact page you came from), HSTS when you are behind TLS.
But there is also the part no software can fix.
Which is to say, it is time for the uncomfortable section, and it applies to littleFedi just as it does to any other ActivityPub implementation. If someone tells you otherwise, they are selling you something that does not exist.
**Public posts are public.** When you publish, a copy is delivered to every server that has at least one of your followers, and to every relay your instance is connected to. Those copies are on machines you do not administer. There is no way to call them back.
**Direct messages are not end-to-end encrypted.** In the fediverse a DM is a post with `direct` visibility. It sits in the clear in your instance's database and in the clear in the recipient's instance database. Whoever administers either server can read it. Do not use fediverse DMs for anything you would not put on a postcard. This applies to littleFedi, it applies to Mastodon, it applies to everyone. We are thinking about a way to encrypt DMs between littleFedi instances, but that could not apply with other software, and it risks giving a false sense of security.
**Followers-only is a convention, not a lock.** You tell the remote server "this is for followers only". The remote server, if it is honest, respects that. If it is not, no amount of encryption is going to stop it.
**Deleting means asking to delete.** littleFedi sends `Delete` activities to peers and has a queue with retries. If a peer is offline, or uncooperative, that copy stays where it is. That is a limitation of the protocol, not a bug.
And what if I delete my account?
I wrote this part carefully, because it is where a lot of software pretends.
When an account is deleted, a single transaction removes: posts and boosts, polls, options and votes, notifications (both received and generated), mentions, favourites, emoji reactions, bookmarks, link previews, home feed rows, attachments, filters and filter keywords, scheduled posts, push subscriptions, OAuth tokens, sessions, lists, followed tags, featured tags, blocks and mutes (in both directions), follows (in both directions), relays, read markers, personal domain blocks, password resets, email verifications, digest state, MFA recovery codes, exports, imports, reports, generated invites, and finally the account row itself. Counters on other accounts and other posts are recalculated, not left out of sync.
The actual files, meaning media, export archives and import archives, are deleted from storage, whether that is a local disk or S3.
What **stays**, and I am saying so explicitly:
- **Tombstones.** A row with a URI, the original type and a date. They exist so that deleted content is not resurrected when a peer offers it back to us. The ones for posts have a configurable retention, 90 days by default. The one for a deleted actor stays indefinitely, but it holds nothing but URI, type and date.
- **The moderation log.** Administrator actions stay, because an audit log you can delete is not an audit log. The template suggests 2 years.
Deletion has a window: peers are notified first, then it is finalised. There is a deadline past which it is finalised anyway, because at that point the right to erasure of someone who is here outweighs an unreachable peer.
But you can take your data with you.
There is the account export: a ZIP with `account.json`, the media index and the media themselves. It is served with `private, no-store`, it has an expiry, and a cleanup job removes it from storage. The template suggests 24 hours and a single download.
There is the import, which accepts the same format. And there is migration to another instance. The archive uploaded for an import is deleted as soon as the import succeeds.
What if you use littleMesh?
Anyone running an instance behind NAT with littleMesh has one more surface, and I want to be precise here too, because it is already written in the documentation.
The **lighthouse** relays encrypted circuits. It does not read the contents, it cannot impersonate a node, and it has neither the mesh key nor the actor key. But it does see which node IDs open circuits to which, with what sizes and what timings. **littleMesh solves reachability, not anonymity.** If anonymity is what you need, an onion service is the right tool, not this one.
The **HTTPS gateway** is a different matter: it is the one terminating TLS for non-mesh servers, so it sees the traffic. That is written in the trust table in the documentation, in plain terms, along with what it can and cannot do.
The default exposure is `federation`: discovery, inboxes, objects, actors and public media get through. The web interface, the authentication pages, the Mastodon API and the media proxy do not.
## Retention defaults, all in one place
| What | Default |
| --- | --- |
| Sessions | 30 days, then removed |
| Remote posts | 30 days (`prune_remote_statuses_after_days = 30`) |
| Remote media cache | disabled; if enabled, 720 hours |
| Terminal jobs | 24 hours |
| Post tombstones | 90 days |
| Your own posts | never, unless you ask |
| Moderation log | indefinitely |
| Access log | your system keeps them, not littleFedi |
You can have your own posts pruned automatically, by age and with like and boost thresholds, if you want a timeline that forgets. And there are self-destructing posts with a per-post timer. But those are things you choose, not things I decide for you.
There is something the software cannot do in your place, though
If you open an instance to other people, the code cannot write your privacy policy for you. It cannot decide the lawful basis, the jurisdiction, the subprocessors, the policy on minors, the breach notification timelines.
That is what `docs/instance-policy-template.md` is for: an operator checklist with a starting retention table and a list of what an honest privacy policy has to cover, namely federation of profiles and posts to independent servers, caching and proxying of remote content, email, push endpoints, logs, moderation records, backups, exports, imports, tombstones, where the data lives and how people exercise their rights. It is not legal advice and does not claim to be.
Moderation, privacy and security contacts, the rules and the terms of service are published from the admin console without restarting anything, and they land on `/about`, on `/terms` and in the instance APIs.
In two lines...
...littleFedi collects what it needs to work and nothing more. One IP address per session, shown to you and revocable by you. No analytics, no telemetry, no third parties, no phoning home. We do not know how many of you there are or who you are, and we have no interest in finding out. EXIF stripped by default, remote media proxied by default, metrics off by default, secrets hashed at rest, deletion that actually deletes.
And then there is the fediverse, which is a publishing protocol. What you put on it in public is public, DMs are not encrypted, and deleting is a polite request to other servers. littleFedi does not change that and neither does anyone else. Once you know it, you can live with it perfectly well.
#littleFedi #littleOne #Fediverse #OwnYourData
https://littleone.littlefedi.social/media/01a02026-fed1-7b07-aea7-2605f07e16d0/image.png

2026-08-20 16:18:11 UTC

The "roost" theme reminds me the early days of a famous social network.
Unfortunately, its char limit has always been too low for me, and I haven't been that active there.
Still, I liked the interface.
#littleFedi
https://littleone.littlefedi.social/media/01a01ff7-35f0-7e7d-8f60-72f787c2f33e/image.png

2026-08-19 19:47:04 UTC

Here’s a small preview of the feature, straight from littleFedi on my private test instance.
#littleFedi #littleOne
https://littleone.littlefedi.social/media/01a01b90-1bac-74f2-9313-9ce644c58e81/image.png

2026-08-19 19:13:59 UTC

# Strangers
I keep a terminal window open most evenings, more out of habit than need, tailing the access log of one of the littleFedi test instances while I think about something else entirely. That's how I noticed it the first time: *a fetch from a Threads host*, correct in every way ActivityPub asks it to be, asking for someone's outbox.
Nothing wrong with it, technically. And yet I sat there for a while, thinking about the person behind that account, and whether they'd have wanted a company that size reading what they wrote, simply because the protocol says anyone can ask.
**So we built a way to say no**, but only to strangers, not to friends.
An instance still federates in the open *by default*, the way ActivityPub expects, because that's what almost everyone wants and I wasn't going to take it away from them. What changed is that an admin can now flip to an **exact-host allowlist**, from the console or from the command line, and it happens immediately, the switch is simply true the moment you set it. Once it's true, reads on posts, on the followers list, on the outbox, all start asking for a signature, and only the hosts you've named get an answer back. Discovery stays open regardless, because a peer that doesn't know you exist yet still needs a way to find out, before it can even be told no.
I went back and forth for a long time on what should happen to a peer once you remove them, or once you switch the whole instance back to open. In the end nothing gets deleted, not the account, not the relationship, not a single post or piece of media or anything cached from them. Traffic stops, that's all. I've never liked the idea that moderation means destroying what someone wrote, as if the words themselves were the problem and not who gets to see them.
**There's a list**, if you want it, **of the big commercial names**, the ones like Threads that started this whole conversation. It updates once a day over HTTPS, quietly, and if the update fails it just keeps yesterday's copy instead of leaving your instance with nothing. **But whatever an admin decided on purpose always wins**. Allow someone by hand and the list can't undo it. Suspend someone by hand and even an allow can't undo that either.
If you're bringing a block list with you from somewhere else, plain text works, CSV works, and so does the Mastodon export with all its fields, severity and everything. Ten thousand rows at most, checked before a single one is written, and you get to look at what's about to happen before it happens.
One thing I'll admit, since it will trip someone up eventually: matching is on the exact host. A peer that splits its actors and its inboxes across different addresses needs every one of them on the list, not just the one that looks like the main domain. It's the kind of mistake that fails closed instead of open, which is the direction I'd rather be wrong in, but it's still a mistake waiting to happen, so it's the first thing in the documentation.
I still think about that line in the log sometimes. A small server should get to say no to a stranger.
**Now it can.**
#littleFedi #littleOne #Fediverse

2026-08-19 12:47:11 UTC

Anyone asked for **emoji reactions**?
#littleFedi #littleOne

2026-08-18 19:14:23 UTC

A new build is up & running.
Enjoy!
#littleOne

2026-08-17 19:20:21 UTC

Hello, friends of the #littleOne instance!
I've had full days, so couldn't take care of this instance as much as I wanted to. But the devs kept working on your bug reports, so I'll push a new build in the coming days.
Stay tuned!

2026-08-14 19:13:37 UTC

**Currently back to the VPS**
I'll move back to the Orange PI when I'll have more time to perform more tests. Meanwhile, "enjoy the powwwaaaaarrrr"
#littleOne #littleFedi

2026-08-14 13:08:26 UTC

Dear #littleOne friends,
**Current status**: I've carried out a few measurements and changes. I fixed the backup issue, which was causing deadlocks in the queue until manual intervention. This morning it was stuck for about an hour and a half, resulting in a backlog of 1,900 jobs, which were cleared in less than an hour.
CPU load is very, very low, better than I expected. However, I occasionally notice some slowdowns that I suspect are due to the WASM driver currently used on NetBSD ARM (v6 and v7), which limits the number of database connections, even for read-only operations. I’m currently investigating this. But hey - do we really plan to host 40 users instances on such a low power device? (*Yes, we do!*)
The instance will likely return to the VPS soon, as soon as I finish looking into it, while we roll out further changes.
Stay tuned!
#littleFedi

2026-08-13 17:47:14 UTC

# How background workers work in littleFedi
Every littleFedi instance runs a background job queue. Jobs are split by kind, but they all share one thing in common: they sit in a database table and are executed by the "main" worker pool, whose size you control with queue.workers (default min(8, GOMAXPROCS), 1 on the low\_power preset).
The kinds fall into two groups:
- **Heavy**, mostly CPU/DB-bound work - inbox (ActivityPub signature verification, actor fetches, home-feed fan-out) and media\_cache (image decoding). These block a worker synchronously while they run.
- **Light**, mostly network-bound outbound work - delivery (one signed POST to one remote inbox), its delivery\_fanout expander, push\_notification, and send\_email. These are short and often latency-sensitive: a boost that hasn't landed yet or a push that hasn't arrived is visible to real people.
By default every worker can pick up any kind of job. That is perfectly fine for most instances. The only caveat: job priority only orders queued rows, it cannot preempt a job that is already running. So if a slow inbox or media job is occupying the single (or few) workers, timely outbound delivery, push and email can end up waiting behind it.
light\_workers (default 0, disabled) spins up a second, dedicated worker pool for exactly those four light outbound kinds. It is a strict either/or, not extra capacity: with light\_workers > 0, delivery, delivery\_fanout, push\_notification and send\_email run only on this pool. The main pool stops touching them, even when idle, and there is no overflow between the two. So workers=8 + light\_workers=2 gives outbound federation exactly 2 workers, not 10.
The light pool also yields to interactive requests like the main one does, but with a shorter wait (3s vs 10s) when both compete for the single foreground-recovery slot - so short, people-visible outbound jobs win that one job while every other worker keeps yielding to keep the web UI responsive.
It's totally optional.
With 0 (the default) all four kinds stay on the main pool. The extra goroutine(s) cost is negligible even on constrained hardware.
**It can be useful for:**
- low\_power devices (e.g. Raspberry Pi or similar): keep workers=1 for the heavy inbox/media work and enable light\_workers=1 so outbound delivery, push and email keep flowing even while your single main worker is blocked on a slow inbox job. This is the recommended combination on a small box.
- Instances where inbox/media loads spike: a burst of incoming activity (a big follower purge, backlog of signature-verification work) can stall time-sensitive outbound delivery on a shared pool; giving the light kinds their own pool decouples them.
- Visibility matters: push notifications and federation delivery are things users notice immediately; if you care about their latency on a busy instance, the dedicated pool is a cheap way to protect it.
Running a single pool is the right default for most instances. Also note both pools share the DB connection limiter (sized from MaxOpenConns): the database is the serial resource, so worker counts beyond the connection count buy nothing, extra workers just deepens the queue in front of it. Size light\_workers for your real outbound throughput.
#littleFedi

2026-08-13 10:48:06 UTC

*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!
#littleOne #littleFedi #SBC #NetBSD
https://littleone.littlefedi.social/media/019ffabc-7dd5-71c0-a242-ec9c2e6283a6/image.jpg

2026-08-13 07:41:41 UTC

Nasty idea...what if I move this instance...here, for a while, to test? 😉
#littleOne
#note1z8m…vrls

2026-08-13 07:39:25 UTC

We need moooooarrr tests!!!
#littleFedi
https://littleone.littlefedi.social/media/019ffa0f-c4fe-7641-8159-712968ed39c7/image.jpg

2026-08-13 07:18:35 UTC

Last night, the VPS load monitoring for this instance showed a progressive increase. On one hand, we were expecting it, as the instance grows. On the other, it was higher than anticipated.
Upon investigating, we realised there was an inefficiency linked to two missing DB views, which was generating a mountain of queries whenever a federated activity arrived. Simply creating them was enough: the CPU load upon the arrival of each status dropped from 80% for two seconds to 0.50% for a fraction of a second.
Enjoy the speed 😃
#littleFedi #littleOne

2026-08-11 13:17:50 UTC

- reply

Built-in backups of the database, the configuration and, optionally, local owned media, with a manifest and a restore command.
You can fully export all your contents (including posts) and re-import them into another littleFedi instance. It'll be another account with another handle, but you won't lose any of your contents. Your data stays yours.
#OwnYourData

2026-08-11 13:13:46 UTC

I've received quite a few questions about the use of AI in and around #littleFedi.
So, after discussing it within the team, we've decided to update the FAQ and make our position clear.
It probably won't come as much of a surprise to those who already know me and the projects I work on. But littleFedi is reaching people who don't know me, or us, and I think it's fair to explain where we stand rather than assume they already know.
The short version: littleFedi doesn't use AI. No ranking models, no recommendation engines, no language models deciding what you see.
The longer answer, including how I approach LLMs and code contributions, is now in the FAQ:
https://littlefedi.org/faq.html

2026-08-11 12:43:59 UTC

- reply

the backup procedure is already backing up the blogs, so we’re covered. And yes, that’s a good approach. I’ll try to put it into the todo list. Thanks!

2026-08-11 10:42:25 UTC

- reply

another solution could be put the blog files into the s3 storage, too (if configured) and serve them just proxying the files.

2026-08-11 10:40:22 UTC

- reply

I don't know 😃 Some local automated tests show that 100 users with sqlite are fine, as long as there's not too much concurrency in writing stuff into the DB. For the public server....I don't know as well. The limit will probably be the limit of the hardware I'll be using. There's something to be fixed: blog generation will only work on single process installations, not on clustered setups. I'll probably easily adapt it to build blogs only on one specific machine (the one doing the housekeeping). Still, the blogs will finish into the local file system, so this needs to be sorted, too. But this will come later.

2026-08-11 10:32:59 UTC

- reply

this server will be permanent.
I'm planning to add a "public" server. I'm not sure if it will be this (using sqlite, we could hit some limits) or another one, using PostgreSQL, ready to scale.
But yes, this is our littleOne and will stay.

2026-08-11 09:12:22 UTC

**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!
#littleFedi #Fediverse

2026-08-10 19:59:27 UTC

- reply

welcome!

2026-08-10 15:09:35 UTC

I tracked down a bug that caused some notifications to fail during a blog regeneration if all the workers were busy. If I haven't replied to you, it's because I might not have seen your messages.
The latest build should have fixed the issue. Sorry about that!
#littleFedi

2026-08-10 09:13:00 UTC

# Just a little reminder on littleFedi's efficiency
The instance [https://rpi0w.stefanomarinelli.it](https://rpi0w.stefanomarinelli.it) - with my user @npub1a8m…cdsn - has been running for over a month on a Raspberry Pi Zero W powered by **NetBSD**.
Under normal operation, it uses 58 MB of RAM, including caches. And it shows no signs of slowness!
#littleFedi #NetBSD #RunBSD #OwnYourData
https://littleone.littlefedi.social/media/019feaf2-5de9-79de-b25f-3b1df532312a/image.jpg

2026-08-09 18:35:56 UTC

Added the */blogs* route, with a list of all the published blogs. It's opt-out, so you can disable it in your settings page: [https://littleone.littlefedi.social/blogs](https://littleone.littlefedi.social/blogs)
#littleFedi

2026-08-09 13:49:54 UTC

Everyone loves text formatting, but not everyone loves Markdown.
**We've got you covered.**
I'm merging a branch that includes a *WYSIWYG* editor, which will translate the output directly into Markdown.
No more tags to remember when writing your next post (or blog post), just a convenient, predictable editor.
What do you think?
#littleFedi #Fediverse
https://littleone.littlefedi.social/media/019fe6c9-8362-7f2f-9961-0f2547bf5cc0/image.png

2026-08-09 11:16:18 UTC

The next branch I'm going to merge into main contains something a lot of people will like. I won't spoil anything, but it addresses one of the most frequent criticisms I've seen regarding similar solutions... stay tuned!
#littleFedi

2026-08-09 11:00:38 UTC

# littleFedi media management
Are you worried that your low-power device will be overwhelmed by external media caching?
**Don't worry, we've already thought of that!**
littleFedi offers 4 media management options:
* **"No caching, no proxying":** Media is fetched directly by the user from the originating instance.
* **"Proxy only mode"** (like this instance): The instance proxies requests so media is always served to the user through it. The originating instance will never see littleFedi users' requests.
* **"Lazy caching mode":** Requests are proxied and then cached locally, so subsequent requests are served directly from the local cache.
* **"Full caching mode":** Similar to Mastodon, it fetches and stores media locally as soon as it is processed by the instance.
For both caching modes, you can store media locally or use an external S3-compatible service. Moving between storage types is supported natively, without needing external tools like rclone.
#littleFedi #Fediverse

2026-08-09 09:11:42 UTC

# New littleFedi build on littleOne
littleFedi **26.08.09** - the changes in this build compared with the previous
deployment.
## Followed hashtags in the main navigation
Your followed hashtags are now one click away: a **Hashtags** entry (with a
hashtag icon) has been added to the desktop navigation bar and the mobile
account menu, pointing at `/tags`. The label is translated in every supported
language.
## Blog posts show a link back to their permalink
Posts that have been published to the blog now carry a small **Blog** chip in
the status meta line. It links to the post's readable permalink
(`/@user/blog/<slug>/`) and works on timestamps and boosts, so readers can jump
straight from the timeline to the polished blog version of a long post.
## Status meta line reworked
Every marker on a status - visibility, language, blog chip, expiry - is now
rendered as the same uniform chip in a single wrapping flex row, instead of a
mix of right-aligned inline boxes. Posts that carry several markers read as one
neat line rather than a ragged stack. The Ink and Roost themes were adjusted to
match.
## Robustness: orphaned-account posts no longer break the page
Previously a post whose author account no longer resolves (a purged account, or
a partially hydrated cache entry) could fail the whole timeline render. Now any
status - including the target of a boost - whose author is missing is silently
skipped. Covered by a new test.
## Icon updates
- Catch-up view and its navigation entries now use a **VHS** icon instead of the
old sparkle (thank you for the suggestion, @npub1mlw…p8fc ).
- The "redraft" action gets a proper **undo** icon.
- The **Appearance** and **Blog appearance** settings sections get a palette
icon.
- New **hashtag** icon for the navigation.
## Blog theming fixes
- Proper spacing restored for non-paragraph content in the post body: headings,
bullet/numbered lists, horizontal rules and code blocks now breathe instead of
collapsing against each other.
- A post with a single attachment now renders a full-width figure (the old
grid left a small thumbnail stranded at the left edge).
- The "View or reply in the Fediverse" link is now consistently styled.
- **Ledger** theme: long code lines scroll inside their block instead of
breaking out past the reading measure.
- **Marginalia** theme: the thread link, replies and pager now align to the text
column on wide screens, and print output was cleaned up.
If you publish a blog, regenerate it so the fixes apply: **Settings → Blog
appearance → Rebuild blog now**. The blog's `style.css` is assembled at build
time, so it only picks up these changes when you rebuild.
#littleFedi #littleOne #Fediverse

2026-08-08 18:49:44 UTC

- reply

no AI features here. Good old deterministic computing.
It's a simple algo that will consider the people you follow. At the end of the page, there's a complete explanation:
Why am I seeing these posts?
Each post scores on signals this instance already holds, and the score halves as the post ages. Nothing is fetched from anywhere else, and nothing learns from what you open:
+2.5
per account you follow who boosted it
+1.0
× log of the favourites seen from here
+0.8
× log of the boosts seen from here
+0.6
× log of the replies seen from here
+1.2
you favourited, boosted or replied to this author in the last month
+1.0
carries a hashtag you follow
+0.8
continues a conversation you took part in
-1.0
the post is a reply
12h
the score halves for every this many hours since the post reached your feed
Your own posts, and anything you already favourited, bookmarked, boosted or replied to, are left out. At most two posts per author. Twenty entries, then the page ends: there is nothing more to scroll.
Your blocks, mutes and filters apply exactly as on every other timeline.

2026-08-08 15:13:36 UTC

- reply

welcome!

2026-08-08 14:41:47 UTC

This is the blog that #littleFedi generates from my posts, when I enable the "Blog Post" toggle: https://littleone.littlefedi.social/@stefano/blog

2026-08-08 14:02:53 UTC

I just built the merge with the branch that enables blog themes, including a few default themes. So, I've enabled the blog for everyone. If you want to test it out... it's live! 😃
#littleFedi #Blogging #Blog #OwnYourData

2026-08-08 10:02:35 UTC

Dear friend of the #littleOne instance,
you can go to your settings page and...enjoy the themes!
#littleOne #littleFedi #Fediverse

2026-08-08 08:13:10 UTC

Some friends are joining the Fediverse from other social networks and have fond memories of the old Twitter days. **We thought of you**, and we’re now merging the branch that brings theming support!
Soon, on littleOne, you’ll be able to choose from a selection of predefined themes.
**Stay tuned!**
#littleOne #littleFedi #Fediverse
https://littleone.littlefedi.social/media/019fe06e-df74-7846-a0d3-a90fb5aa3b8e/image.png

2026-08-07 21:55:34 UTC

The discussion is going on late into the night, but the decision has already been made. Tomorrow we will try to merge a branch with a very particular change…
#littleFedi

2026-08-07 15:45:41 UTC

# 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](https://codeberg.org/grunfink/snac2), 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](https://my-notes.dragas.net/2025/06/23/taking-a-semi-truck-to-buy-salad-my-manifesto-for-simple-computing/) 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](https://comam.es/snac/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.
#littleFedi #Fediverse

2026-08-07 15:00:05 UTC

# Update since yesterday:
**New**
- Opt-in federated RSS feed for your account
- Threaded federated replies now show up on static blog posts (merged from an experimental branch - works but not pretty yet, it's a start, watching it closely)
- New followers can require your approval before they're accepted - it was there, just hidden
- Default language, Markdown, and audience settings for new posts (replies/edits/redrafts keep original settings)
- DM button and blog badge on profile pages
**Fixed**
- Follow/unfollow path
- Video playback
- Search now resolves pasted remote status URLs directly
- RSS/blog reply preferences carry over on account export/import
- Profile pane improvements
All live now. Let us know if anything looks off!
#littleFedi #Fediverse

2026-08-06 12:46:38 UTC

# 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.
#littleFedi #PWA #OwnYourData #Fediverse

2026-08-06 11:29:12 UTC

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.
#StayTuned

2026-08-05 13:09:55 UTC

The first batch of invites has been sent. Here we go!
#littleFedi #littleOne

2026-08-05 09:51:43 UTC

# Hi everyone, I'm Stefano
Also known as the *BSD Cafe* and *illumos Cafe* barista - @npub1ef5…gcpc and @npub1gac…4w3w
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.
#littleFedi #littleOne #Fediverse