After the (temporary) defederation announcement of earlier i checked the Lemmy repo to see if there was already a ticket on the federation limiting option like Mastodon’s that people mentioned Lemmy doesn’t yet have. Not only i didn’t find it, i also saw that there’s about 200+ open tickets of variable importance. Also saw that it’s maintained mostly by the two main devs, the difference in commits between them and even the next contributors is vast. This is normal and in other circumstances it’d grow organically, but considering the huge influx of users lately, which will likely take months to slow down, they just don’t have the same time to invest on this, and many things risk being neglected. I’m a sysadmin, haven’t coded anything big in at least a decade and a half beyond small helper scripts in Bash or Python, and haven’t ever touched Rust, so can’t help there, but maybe some of you Rust aficionados can give some time to help essentially all of Lemmy. The same can be said of Kbin of course, although that’s PHP, and there is exacerbated by it being just the single dev.
You never heard of Rust? Today’s lucky ten thousand then. I’ve personally never had a chance to use Rust, but it’s my #1 most interested in language based on all the things I’ve heard about it.
Though I’m personally on kbin and naturally there’s the most interest in fixing issues that are on your instance. Kbin sadly is just PHP, but whatever. I was gonna make a bug fix yesterday, but the steps to turnup a dev instance are so long that I got lazy and didn’t bother. I’m spoiled by all the servers at my work that I can just start running with a single command that having to spend potentially a few hours turning up a server feels like too much now (and let’s be honest, setting up a dev env is the most boring and annoying part of our job).
Just really needs some time invested in a docker compose solution, can easily spin up a dev env even with PHP.
It has one. Minus an undocumented step (that’s sat fixed in a pr). Bringing it up amounts to 4 lines in a console; 1 to bring up the stack and 3 to start a JS watch for asset compilation.
How did you find the config file setup? That was where I looked at the file and decided “ah, I don’t wanna deal with this”. I just wanted to test what I expected to be an easy fix. If the code in question had unit tests, I would have just used those, but I didn’t see tests. Actually, now that I think about it, I’m used to test files living alongside dev files, as is the Go convention, but maybe it’s like the Java convention with tests being in a mirror folder tree. I should check later.
There are tests (and if the readme is to be believed a 71% coverage) they live in the top level tests/ folder.
As to the .env file you just need to rename the example one and either amend these values (with appropriate urls)
SERVER_NAME=localhost KBIN_DOMAIN=localhost:9443 KBIN_STORAGE_URL=https://localhost:9443/media MERCURE_URL=https://localhost:9443/.well-known/mercure MERCURE_PUBLIC_URL=https://localhost:9443/.well-known/mercure CADDY_MERCURE_URL=https://localhost:9443/.well-known/mercureOr add them to a new
.env.localfile.Start it all up and jobs done*
*well, you need to run the asset pipeline and add an admin user but that’s all in the Readme.