Questions people ask

There is no date. The code is beta, the release checklist still has open rows, and publishing a repository is a commitment to the people who then run it. This site exists so the design decisions can be read and argued with before that happens, not to build an announcement list.

Yes. The licence is chosen and the notices are written. Every dependency linked into the release binaries is permissively licensed, MIT, BSD, ISC or Apache-2.0, as are the embedded web assets, and their notices ship inside every release tarball.

An informal group of computer enthusiasts whose members, except me, have chosen to remain anonymous. I am the project's public representative, maintainer and copyright holder. The name is a nod to the 1985 computer game. See About.

No. It is not a company, an association, a foundation or any other incorporated entity, and the project notice says so explicitly so that nobody has to infer it.

A machine, a domain, a certificate, and a reverse proxy. The binary is static, the database is embedded, and there is nothing else to install. If you do not have a public address, littleMesh removes the domain, the certificate and the open port from that list.

That is what low_power = true is for, and ARMv6 and ARMv7 binaries are built for both Linux and NetBSD. A Pi Zero W running NetBSD is a target, not a joke: give it a few seconds to settle its cache and you stop noticing what it is running on. Whether it runs well with your particular follower graph is still a measurement rather than a claim, so take it before you promise anyone an account.

SQLite unless you have a reason. It is embedded, it needs no second process, and it is what the one-process profile is built around. Choose PostgreSQL when you want several processes sharing one instance, or when you are on illumos or 32-bit NetBSD, where the embedded SQLite falls back to a slower interpreter with one connection and a capped heap.

There is a supported one-off path for a single-user Akkoma or Pleroma instance on the same domain. It keeps the actor URI and the RSA key pair, so remote servers never notice the switch, and it carries the profile, the followers and the following list. It does not carry old posts, media, favourites or pinned posts, and old post permalinks will 404. That is stated up front because it is the part people discover too late.

Yes. OAuth, the REST API, WebSocket and SSE streaming and Web Push are Mastodon-compatible, and the legacy flow without PKCE still works for clients that need it. Client certification is recorded in the compatibility ledger, and those rows are still pending.

Yes. A LAN-only deployment works, and mesh nodes that can reach each other directly skip the relay entirely, so two machines on the same network federate without anything in the middle.

Because a feed that decides what you should see is a feed you cannot reason about, and because the moment ranking exists everywhere, every posting decision becomes a bet on it. The one ranked view, catch-up, lives on a separate page you have to open, shows twenty posts, always tells you why each one is there, and stores nothing about what you looked at.

Instance-wide popularity is a moderation surface, an abuse target and a thing people optimise against. The endpoints exist and return empty results, so clients behave correctly instead of erroring.

No. There is no ranking model, no recommendation engine and no language model deciding what you see. Timelines are chronological, catch-up tells you why each post is there, and trends and suggestions return empty on purpose. The rules are written down. You can read them. I do not think people need AI to talk to other people.

Software seems to need more of everything these days: more memory, more CPU, more storage, more bandwidth and, increasingly, more GPUs. littleFedi goes the other way. It is built to run on old computers, small boards, and machines that would otherwise sit unused in a cupboard.

As for the code: I do not use LLMs for the code I publish. littleFedi is not only my work, though, and I can only speak for myself. Nobody can honestly certify the origin of every line of code in an open source project today. A contributor can tell me they wrote something. I have no way to prove it, and no intention of pretending otherwise. I see the same problem in my professional work every day. What I can review is the code. Is it understandable? Is it maintainable? Is it correctly licensed? Does it improve the project? Those are questions I can answer.

Because a social server is infrastructure, and infrastructure should not stop working because a bundle failed to load, a browser is old, a connection is bad, or someone reads the web with scripting off. Pages are rendered on the server; JavaScript improves them and is never required by them.

Because I run them, and because a static Go binary makes the cost almost entirely packaging. What differs between FreeBSD, illumos, Linux, NetBSD and OpenBSD is where files go, which service manager starts the process, which firewall admits the ports, and where the logs land. Each gets its own guide and its own service definitions, and none of them is the default with the others bolted on afterwards.

Because a passing test in a repository is not a passing test against a real peer, a real object store, a real device, a real restore or a real 24-hour soak. Those checks have a written list and open rows. A pending row is a release blocker, and calling it anything else would be lying to whoever deploys this.

Yes. littleOne is the official instance, and it runs the same server this site describes. It is invite only for the moment, which is the same advice given to everyone else on this site: do not open registration until somebody is willing to moderate.

You do not need an account to look at it. Signed-out visitors land on the local timeline, so the interface, the themes and the rendering are all visible from outside, with no JavaScript required.