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.mdto 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.
You must log in or register to comment.
one for the FAQs:
Q. Why a fork? Why not just contribute to Lemmy upstream?
A. The Lemmy devs aggressively don’t want to hear from Lemmy site admins about problems, and frequently don’t seem to understand the problems. Many site admins have tried to work with the project and given up in frustration.
e.g.
https://wedistribute.org/2024/03/lemmy-image-problem/
https://lemmy.ml/post/12829700
https://my.jewy.blog/my-love-hate-relationship-with-lemmy
https://lemmy.ml/comment/8968867
https://literature.cafe/post/7623718We appreciate and are grateful for the Lemmy developers’ considerable efforts to build discussion forum software that works well enough to sustain a social network. However, the practical issues with direct contribution remain.
As Lemmy developer nutomic said (archive):
if you leave Lemmy it means less work and less complaints for us.
We are taking him up on this offer.
Our code remains under the same license (AGPL 3) and is fully available for reuse by the upstream project, or anyone else.
but you see, you can’t get modtools, because nutomic has a critically important task of creating tankie wikipedia
suggested site decoration
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-controlin 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
as a whole, the Lemmy codebase feels like an excuse to play with technology the authors liked but weren’t particularly knowledgeable in.
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
I guess the next fork will be “Fast” then.
I’d love to help when I have the time. I know a bit of Rust but am fairly confident in TS/React.
I just spent an hour trying to get the backend run locally on my macOS machine without success so far. First,
cargo buildfailed because of a linker error, but that was pretty straightforward. So for anyone running into the same error, just do this:brew install libpq brew link --force libpq cargo clean cargo buildThen there was an error connecting to the database. Which is strange, because I was pretty sure I had postgres installed. After some digging, it seems that this is a problem with
postgresql@14specifically and does not occur with earlier versions, so I downgraded to 13. With that,cargo runfinally executed, but I ran into an actual error here.>> Error: LemmyError { message: Unknown("Couldn't run DB Migrations: Failed to run 2023-07-08-101154_fix_soft_delete_aggregates with: syntax error at or near \"TRIGGER\""), inner: Couldn't run DB Migrations: Failed to run 2023-07-08-101154_fix_soft_delete_aggregates with: syntax error at or near "TRIGGER", context: SpanTrace [] }I gave up for now. Debugging database migrations is probably the closest thing to the Basilisk torturing me for all eternity that I can imagine. If anyone knows what this is and how to fix it, I’d appreciate it.
it isn’t just you; this very frustrating lemmy github thread has a bunch of other developers that ran into it too. there are a few workarounds in there — it looks like the official method is to use lemmy’s dockerized setup for everything, of course, but it seems there’s a few other ways forward if you’d understandably prefer not to use docker.
lemmy depending so hard on its weird docker environment is something I really would like to fix very soon
lemmy depending so hard on its weird docker environment is something I really would like to fix very soon
(to let this rant out just a tiny bit:) it is infuriating how much more rope container-based workflow has given the “works on my machine” dipshits of the world
it has also minorly improved the problem in that if they have to ship container construction workflows (which by and large are Dockerfiles, but…) then you get to see what kind of insane bullshit they pull to do this. but then at the exact same time you get to see that bullshit, which instantly makes things worse again. 1 tiny step forward, 300 paces of frenetic running away in horror
Oh for fuck’s sake. They depend on postgresql@16 but in their official documentation they say to use
brew install postgresql, which installs 14 as that’s the current stable/LTS/whatever in the brew repos.brew remove postgresql brew install postgresql@16 brew services start postgresql@16 $(brew --prefix postgresql@16)/bin/createuser -s postgresAnd then run the Lemmy
db-init.shscript. Now it works.At least I didn’t have to use Docker.
lemmy depending so hard on its weird docker environment is something I really would like to fix very soon
is it just me or is this fundamentally proprietisation?
has anyone bothered checking the docker image for presents?
if they were more technical I’d mutter “Jia Tan mf’s”
Is there any plan to try to push improvements upstream? Or you’re not even going to try?
mergeability is desirable (and itself is a two-way street), but there are various foreseeable problems that could unfortunately limit our ability to merge in the future. there are also items on our roadmap that we understand are uninteresting or undesirable to upstream and so shouldn’t be merged; see the build environment discussion elsewhere in this thread for an example of a planned improvement on our end that is very unlikely to be merged upstream.
Fair shout :)
I still think it’s worth a try. If they reject it, nothing lost, no?
sure! anyone who feels that work is important and wants to do it can take it on — we aren’t in the business of obstructing contributors, and again mergeability is desirable. this isn’t on the top of my personal list, but this fork is in its early stages (we haven’t even renamed anything yet), so it’s definitely possible that one or more parties will come along whose ideal contribution is ensuring patches make their way upstream.
some tasks I plan to tackle this week:
- rebrand this fork to Philthy and replace the README with more of a stub (to be expanded upon later)
- rename our repos to
philthy,philthy-ui, andphilthy-js-clientif doing so won’t break other developers. I’ll need to see what Codeberg does when repos are renamed. - we currently have a single-user testing instance at making.awful.systems. this effort likely won’t finish this week, but I’d like to come up with a plan that’d use Codeberg’s Woodpecker CI to kick off deployments to that test instance whenever we’ve got new code in
main. there are still some open questions around how to coordinate the versions oflemmy,lemmy-ui, and the deployment flake; I might need to refactor the current test instance to work better in a CD workflow. longer term, I’d like to be able to spin up a testing container for a pull request on demand, but that kind of thing’s definitely harder to do when you’re hosting it. - run
nix flake lock --update-input lemmy-translationsinlemmy-uito pull new translation strings from upstream (should hopefully fix some missing UI labels I’ve noticed)
as always, guidance on all of the above is welcome. if anyone has a strong preference for a CI or a suggestion for a container management framework they’ve used for something similar and enjoyed, or there’s a low-hanging fruit feature or fix I might be able to fit in this week, definitely post it here. my only ask for infrastructural stuff is that it’s a good fit for a flake-based NixOS deployment like awful.systems, and ideally that it works well with Codeberg.
I’ve renamed the repos to reflect the fork name. please let me know if this broke anything for you, if you’ve got a fork or clone of the repos under their old names!
currently I’m working on updating our inter-project Nix, npm, and git submodule dependencies to point at the new repo URLs
