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 @vortex@tldr.nettime.org - 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

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

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

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

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

„If the Social Web isn't just for nerds, why are we saying stuff like this to newcomers:

Okay, so the fediverse is like, a bunch of interconnected servers, all talking to each other. They all use the same open protocol, so the whole network is interoperable, and anybody can self-host their own new server whenever they want. You can get on the fediverse through any server. We call these servers »instances«. If you wanna join fedi, you can just go to this website and pick an instance to sign up through. All the instances are referred to by names like mastodon.social, because we like to use domain names for some reason.

(...)

We must keep this in mind when trying to sell the Social Web to people. Normal people don't know what »federated« means — they didn't watch Star Trek, they just think you're a cop. Normal people really don't know what a protocol is, or what interoperability means. Stop talking like this. I also don't know why we're using the word »instance« to refer to servers. Server is literally easier to understand even for tech people. Even better than server would be »site«, which is the terminology that I tend to use.

Here's a better explanation of the Social Web that actually communicates the idea to a normal person:

The Social Web is like social media away from Big Tech. Instead of being a walled garden where you're trapped, the Social Web is like a bunch of different social media websites connected together. You can pick any site to sign up with, and then you can follow people who signed up on other sites too, so it kind of forms one big network, or online space. If you wanna sign up, you can make a Mastodon account (Mastodon is like, one of the categories/types of sites on the Social Web) at this website. You can use the default option, or pick a different »instance« (site) if you want, too. It doesn't really matter which site you decide to sign up with, since you can always change your mind and move to a different one later.“

Interesting text, via @WeirdWriter@caneandable.social

https://riverseeber.net/blog/post/a-reasonable-analysis-of-the-social-web/

#Fediverse #OpenSocialWeb #NonTechies

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.

#introduction #littlefedi #fediverse

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

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, @shom@littleone.littlefedi.social ).
• 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