#littlefedi
Wow, littleFedi shows the "sitelen pona" writing system.
How cool is that? 😀
(However, the signs overflow the content warning field, cc @stefano 🤔)
#littleFedi #TokiPona #SitelenPona #conlang #language
Seeing a little weird jumping of the timeline in #littleFedi. Can't quite recreate it, it happened in the home and catchup feeds and it jumped to the top while scrolling. Firefox on Android. I'll try to find specific reproducible steps.
@stefano are there plans to make it so that a littleFedi user's static blog can migrate with them if/when they migrate between littleFedi servers? Is that even technically possible?
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.
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!
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 😃
Welcome to #LittleFedi where I am testing out the quote post feature
@fd0
Hello World
This is my first post on Little Fedi #littlefedi
Thank you @stefano for granting me access
Hello World
This is my first post on Little Fedi #littlefedi
Thank you @stefano for granting me access
Just installed netbsd on a home Raspberry pi 3 and connected to a domain via Cloudflare tunnel. Just ready and waiting for the first release of #littlefedi. No pressure @stefano 🤣
Good morning!
I just deployed a new build live. It should resolve the Mastodon API login issue with certain apps. I personally tested it with IceCubes, Ivory, and Mona (though with Mona, it might fail initially, if you hit 'X', it asks if you want to continue with Safari - just select 'yes' to proceed, and it will work. I'll look into it later). It has not been tested with other apps at the moment.
I also merged a couple of optimisations for the PWA and improved the Web Interface, which now uses significantly less CPU. Thanks as always for your help!
All the documentation for #LittleFedi is out. Interesting stuff. I have been helping test this project for a couple of weeks and I'm excited. Can't wait for the first beta release
@stefano@bsd.cafe
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!
Logged into littleFedi on an old Nexus 5(x) smartphone that runs Ubuntu touch.
The GUI reacts a bit slow, but that was to be expected.
Otherwise, the timeline and posts render perfectly fine :)
#GoToSocial and #littleFedi keep introducing thoughtful functionality focused on user choice and user empowerment and I'm here for it!
GoToSocial supports importing from previous instance even provides an API for importing non ActivityPub history but both require external tools. littleFedi has built-in backup and full instance restore that seems to be aiming for lower tech know-how. #OwnYourData indeed, hear hear 🍻
@stefano
@shom @fasnix @madamada 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.
The self-destruct option in #littleFedi works like a charm. This is perfect for those messages that you don't care about. After all, cleaning out old posts is a great way to reduce storage needs.
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: