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.
I know rust and react/typescript, so I might be able to help out with this (time permitting).
Is the intention to stay fairly close to the upstream, or make the code less horrible? Also, I haven’t looked at it yet, what makes the lemmy code so bad? Not the first time I’ve heard this complaint.
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.
Hmm the first sign may be that it doesn’t build. I think it’s expecting translations that don’t exist.
Edit: Cargo build fails, nix build succeeds. Edit2: Oops, submodules.
oh god, they put all the structs in the same file and all the impl’s in different ones. Why?
it’s entirely possible they assumed C++’s compilation model applies to Rust
you know, @self has been mentioning things about the awfulness of the codebase and I hadn’t yet gotten to look, but … wow. that’s certainly a Choice.
oh! I forgot to answer this one above but: while preserving upstream mergeability is desirable, you might already have seen an example where that would be a challenge; I’m leaning towards fixing what we can where we can