„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

Big hopes for littleFedi

This was originally posted on my blog.

The Fediverse is exciting, I've formed genuine connections with interesting people. GoToSocial got me hosting my own presence. And I hope littleFedi is what gets to hosting a community.

Thoughts/context on Fediverse

The federated universe (Fediverse) is awesome: different applications, networks, sub-cultures all able to interact with each other via a rather lightweight protocol, ActivityPub. It's this very lightweightness is interesting because not all the servers are architected to be lightweight because they are architected to scale. There's a lot of debate about the role of centralization, discoverability, "flagship" instances this post isn't that. BUT, decentralization is a big selling point of ActivityPub and being able to run many small instances on low power hardware democratizes participation. I'm all about that, GoToSocial fits the bill perfectly and I have been very happy hosting it and the team is doing great and thoughtful work.

Why am I excited about littleFedi!?

Well maybe it's a better idea to talk about what is littleFedi is?! I'll let @stefano talk about that: littleFedi: a Fediverse Server That Doesn't Need a Data Centre. That blog is actually served directly by littlFedi and the post was created as any other regular post AND the blog is statically served AND a regular post can be retroactively turned into a blog post AND it supported threaded comments (since it also remains a regular ActivityPub post). littleFedi has a load of other great features as well and I don't want to take away from that but this is definitely what sets it apart from GoToSocial.

Blogging vs Microblogging

Blogging and maintaining a separate social feed is difficult. The ability to do it all in one platform and also convert existing posts into blog posts if they need to be persisted as a "body of work" is great for folks who don't want to mess around with tech and just want to share with their community. Also it's cognitively easier to write a series of posts instead of sitting down to write a blog post and being able to convert it later is great.

What's next?

I'm on the test instance and have been doing some testing and providing feedback. Stefano is both very prompt and gracious in receiving feedback and fixing issues. The project will be released as a MIT licensed self-hostable application and I plan on trialing a niche community hub (more on that later) using littleFedi. I wish the project well and will be following it closely and eagerly.

#Fediverse #Selfhosting #Blaugust #littleFedi

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

Hi everyone, I'm Stefano

Also known as the BSD Cafe and illumos Cafe barista - @stefano@bsd.cafe and @stefano@illumos.cafe

This is the first post from littleOne (littleone.littlefedi.social), the first littleFedi instance open to outside users.

littleFedi is a new ActivityPub server, still in active development, written in Go and shipped as a single binary. It speaks standard ActivityPub, so it federates normally with Mastodon, snac, GoToSocial, Akkoma and the rest of the fediverse, and it exposes a Mastodon-compatible API, so most existing apps already work with it.

A few things about it that aren't the usual fediverse defaults:

• Catch-up instead of an algorithm. Timelines stay chronological, full stop. There's a separate /catchup page, visited on demand, that ranks what you missed using only signals this instance already has locally - who you follow boosted it, replies and favourites delivered here, hashtags you follow. No external popularity data comes in, nothing about what you read is tracked. It answers "what did I miss" without turning into a feed that decides for you.

• Static blogging built in. Any post can be marked as a blog post and gets published as a plain static page under /@username/blog/, with its own permalink, Atom feed, and no JavaScript or database hit per view, while still being a normal federated post underneath. A proper home for longer writing that doesn't need to compete with a timeline.

• Self-expiring posts. Any post can be given a timer and auto-delete on its own.

• Bubble timeline. A middle ground between local and federated: a timeline scoped to a set of instances you've chosen to group together, not just your own or everything.

• littleMesh. A way to federate without a public domain, certificate, or open port at all - meant for something like a Raspberry Pi behind NAT. Instances get an address derived from an Ed25519 key pair and reach each other through pinned relays that never see plaintext.

• No trends, no suggestions. These are intentionally left empty. Nothing here is trying to surface "popular" content or keep anyone scrolling longer.

• Security defaults taken seriously. Signed federation (HTTP Signatures), optional Object Integrity Proofs, TOTP MFA, audit logs, and full account export, migration and deletion if you ever want your data to live somewhere else.

This instance is here to test all of that with real accounts, not just a small group ones'. In the next few days I'll be reaching out to everyone who already told me they were interested, to set the first accounts up - an invite is coming. If you'd rather just follow along and see how it goes, that works too.

It's a test instance, so expect the occasional rough edge. If something breaks or feels wrong, tell me - that's exactly what this phase is for.

#littleFedi #littleOne #Fediverse #Introduction