BSD Cafe Billboard

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

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

@stefano Have a great week!!

https://littlefedi.org/ a small ActivityPub server written in Go. It ships as a single static executable with a server-rendered web interface, a Mastodon-compatible client API, a durable federation queue, moderation tools, and optional PostgreSQL and S3 support. No runtime to install, no services to wire together. Via https://littleone.littlefedi.social/@stefano/08d20839-b21b-47bc-a1b6-800d1137f36e | https://mastodon.bsd.cafe/@stefano@littleone.littlefedi.social/117076101948770274 @stefano@littleone.littlefedi.social

Bietet deine Instanz / Server / Software die Möglichkeit, dich z.B per E-Mail zu benachrichtigen, wenn dich u.a ein Konto entfolgt oder blockiert? Und lässt du dich darüber informieren oder hast du die Einstellung deaktiviert? Gerne in die Kommentare, welche Software die Einstellungen anbietet. Gerne Boost, danke! #Umfrage #Fediverse #Einstellungen

@tilde there's something like this in the plan. not top priority, for now, but it's there

@erikwesseliusZeker weten @stefano

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

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

To say I am excited about #LittleFedi software would be an understatement. What I am seeing from @stefano and the team breaks new barriers for entering in, and participating in, the #Fediverse. Can't wait to test on a self hosted Pi at home. If successful, I shall migrate my long established Mastodon cloud instance to it and serve all from home on local hardware.

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

I've been heavily poking at littleFedi by @stefano and quite excited about it.I wrote about it in another Blaugust attempt: Big hopes for littleFedi. Also available on my test account ​@shom@littleone.littlefedi.social's post/blog.#littleFedi #Blaugust #Fediverse #Selfhosting

@homegrown@social.growyourown.services @stefano@bsd.cafe thank you for sharing it!

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

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

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

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

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

@crow @stefano@littleone.littlefedi.social @stefano@illumos.cafe this is so easy to install that will be easily bundled: "littlefedi init" and you're ready