nah, there are plenty of truth wannabes (freeze peach bigotry safe havens) that actively federate. just look at literally any competent server’s blocked instances list and you’ll see a few examples. there’s a reason why nobody* runs completely open federation

*: aside from people who’re friendly with that crowd ofc

git commit -m $(date)

DNS blocking is the most unreliable way of blocking youtube ads you can imagine.
you could write a script to OCR your entire screen and click skip ad and it’d be more reliable than DNS blocking

One of the reasons I use containers instead of installing things directly is that i can completely uninstall a service by deleting a single directory (that contains a compose.yml and any necessary volumes) and running a docker/podman system prune -a

or that i can back up everything by backing up a single “containers” dir, which i could have on a subvolume and snapshot if i wanted to

systemd/quadlet on the other hand makes me throw files in /etc (which is where you’re supposed to put them, but ends up resulting in them being tangled together with base system configuration often partially managed by the package manager)

The Solution™ to this is configuration management like ansible or whatnot, which needlessly overcomplicates things for the use cases i need (though they’re still useful for getting a base system “container ready” wrt ssh hardening and such)

tldr: i want my base system to be separated from my services, and systemd integration is the exact wrong tool for this job

i’m using tilt controls!

Logic errors will be a more relevant issue with a web app (things like not setting your JSON Web Tokens to expire) and Rust won’t save you from that.

I’m sure there is some arcane feature of Rust that’d let you encode that in the type checker somehow. Yeah it’d be completely unreadable and unmaintainable but knowing the Rust community there’s probably someone mad enough to take a crack at it.

AFAIK the issues l.w et al are struggling with are to do with the database. The language you’re calling out to Postgres doesn’t really matter when it’s Postgres that’s taking a lifetime computing through your hell-query.

I don’t know much about Go (I should really take a closer look at it) but it’s definitely also a valid candidate. (Perhaps a bit too bare bones for my personal liking, but hey you can’t win em all)

A long-running web thing like Lemmy doesn’t need the processing benefits of native compilation, and can avoid memory vulnerabilities with a garbage collector. Most things it does are IO bound (receive data from other servers, send data to other servers, occasionally render some HTML, interact with a database…) so you’re really not benefiting from anything specific to Rust, but you are losing a significant amount of developer effort into things like working with the borrow checker or the infamously long compilation times that could instead go into implementing functionality.

You could make something just as performant as Lemmy is today with Python or JS (JS would particularly work well given the prevalance of JITs).

I’d been eyeing azorius.net lately considering it’s much smaller/younger than Lemmy and already federates (and might make an interesting foundation to build something out of before it grows too large, hint hint to anyone who actually knows Go) but I don’t have the Go experience to actually go through its code.

I’ve been experimenting with ActivityPub on my own time and I am kinda starting to understand why all AP projects end up being large messes. It’s spaghetti code all the way across the fedi.

Because now you have to maintain that fork. If it was as simple as pressing the little fork button on GitHub and importing a few PRs in than there’d already be several forks right now.

The Lemmy codebase is a beast that’s evolved over several years. Not everybody can just jump in and throw anything they want just because of how complex a system it is internally. (I learned that the hard way.)

Across the fediverse all the major successful forks have a motivating factor. Glitch social is maintained by the only other paid developer hired to work on Mastodon and acts as an unstable branch / “feature fast track” of sorts, Akkoma exists because upstream Pleroma has sided with the freeze-peach crowd too many times to count. Firefish and Iceshrimp had a whole… thing… (too much drama to explain) (oh and upstream Misskey is way too Japanese for western developers to contribute, including commit messages and code comments) What’s the motivation to start a Lemmy fork? And what’s the motivation to keep maintaining it?

I really want to see a Lemmy fork. Particularly one that attempts to prioritize instances as their own individual communities (rather than the Redditesque “instances as free horizontal scaling” view of the fedi a lot of people seem to have). Hell I might end up attempting to contribute a quality of life feature or two of my own if a viable fork were to exist. Yet there isn’t any.

So, I guess what I’m trying to say is, the only reason no fork exists is because nobody has stepped up to the challenge.

EDIT: And of course with ActivityPub in the mix you also have to consider how it will affect federation with other instances, and building consensus among other projects (not necessarily just Lemmy) regarding any extensions you might decide to add to the protocol (though you’d have much easier time implementing extensions from other projects if they solve your issue)

it can be pretty useful for really specific cases, but i’m not exactly sure if this is one of them

the allowed instances list acts as an allowlist, meaning you’d be defederating yourself from the rest of the fediverse (and only federating with the instances you allow).

if that’s what you were going for ofc it’s your right and i sure won’t stop you from doing that, but i feel like you’ve misunderstood what it is.

The Synapse and Postgres containers are using about 2% CPU and 1.2Gb of RAM combined. If your strapped for resources, check them out.

with 1.16G i can run dendrite and iceshrimp (+redis and +sonic, shared caddy and postgres between both). i wouldn’t call synapse the “strapped for resources” server.

*as long as you have a good CPU, a minimum of 32GBs of RAM, about 200GB disk space, fast internet access, and 12 hours of time per clean build (or try incremental builds that will constantly break).

Having maintained my own branch of LineageOS for a while, I would not take compiling Android as lightly.

Have you considered submitting this to the Internet Archive? This seems serious enough to be somewhere outside YouTube. No idea if they’d accept it though considering the legal grey area.

if you have a hard time choosing between Gitea and Forgejo I recommend picking Gitea for now, as they haven’t done anything bad just yet, but if they do Forgejo supports migration from Gitea.

iirc there isn’t an official way of migrating the other way so if Forgejo fucks up you may end up out of luck

it’s partly because everything has public/private certificates, but also partly because there isn’t much synchronization going on after the initial “push”. if you shut an instance down and modify the database directly without informing other instances (say, you remove an account) then other instances will not be able to tell and will drift out of date, essentially making that specific thing unusable for any instance that has previously interacted with it. if you expand that out to, say, wiping and re-creating an entire database, then you end up with so much uncertainty that you may as well start over from a fresh domain

You’d have to be significantly more careful with backups, as it’s really easy to effectively “burn” a domain from federating over AP ever again (at least to instances that federated with it before), but otherwise it should be reasonably automatic as federation gets implemented piece by piece.

Considering the fact that there is a special field in user profiles for a Matrix handle, I imagine upstream would prefer something Matrix-y instead.

Of course I can’t speak for anyone involved. Especially if someone else is thinking of writing the code themselves.

…and of course I learn this after switching to firewalld.

At least firewalld feels relatively painless compared to rest of the redhat-container-verse.