the software we use to run awful.systems, which @dgerard@awful.systems suggested I call Philthy (and I agreed!), is seeking contributors.
like upstream Lemmy, this consists of a Rust backend and a Typescript+React frontend. contributions to both are welcome; use this thread to discuss ideas and collaborate.
here’s some contribution ideas off the top of my head (but all reasonable contributions are welcome):
- (frontend & backend) actually rebrand to Philthy, to prevent confusion between us and upstream Lemmy
- (frontend & backend) rewrite
README.md
to emphasize that this is a fork - (frontend) make the page header and footer more configurable; remove various links that aren’t relevant to awful.systems
- (backend) delete posts from Mastodon when they’re deleted on our end
- (frontend & backend) implement The Firehose, a big admin-only list of the posts and content leaving our instance
- (frontend & backend, ongoing) merge in changes from upstream Lemmy if there are features you wish our instance had
or make suggestions in this thread!
one major blocker preventing folks from contributing to Lemmy-related development I’ve seen is that a lot of people don’t know Rust. if that’s the case, I can offer the following:
- the Lemmy codebase is the worst possible place to learn Rust, but I’d love to start a thread for Rust tutorials and shared learning. it’s honestly an excellent language in its own right, so I’d love to teach folks about it even if they don’t end up contributing to Philthy.
- if you’re good with React and/or Typescript and the feature you want to implement has a backend component, I don’t mind handling the backend portion if I’m able.
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.lemmy was the first example i can remember using of a React based site that is actually zippy and not slow as shit cos it isn’t serving 100 ad trackers
Yes, it feels a lot like some of my personal projects where I play with new tech in some of its structure. But it also has stupid decisions.