thank you! definitely let me know if you’d like a pointer to where something is in the code, or a summary of how anything is architected.

so the problem with Lemmy on the frontend is that it violates a bunch of web dev best practices. a lot of them are pretty easy to spot for someone who’s worked in react before (an example off the top of my head is, the frontend will just throw an exception and show a misleading error page if it can’t parse your JWT. this has broken us in production before). I figure we can clean these up relatively casually, unless we catch something that looks like a security risk (and Lemmy has a long history of those too).

the problems on the backend are a lot more structural — it’s a weird assemblage of sub-crates arranged and typed in a way that makes a lot of types of changes way harder than they really should be. it feels like the kind of rust code someone would write if their main experience was in “enterprise” typescript and they were very new to rust.

as a whole, the Lemmy codebase feels like an excuse to play with technology the authors liked but weren’t particularly knowledgeable in. this is proven out by the fact that they’ve actually deprecated the react/typescript UI and are intent on replacing it with a Rust version using the Leptos framework — a stupendously unpopular choice that seems to be driven purely by the desire to write more rust and use more experimental technology, regardless of the consequences to the project.

there’s also just a ton of systemic weirdness to look out for. for example, Lemmy really doesn’t like running outside of the preconfigured docker container it pulls some of its metadata from (including its version, even though cargo.toml and package.json are right there — this data being missing will silently break cache-control in a very destructive way). I’ve fixed some of that weirdness already just to get a Nix flake version of the software working, but I’d like to fix these breakages in a more cross-platform way too.