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.
from having spoken with @self on this (and without meaning to put words in their mouth), I believe this is meant to live all on its own. think I’ve seen the same from @dgerard’s comments on the matter
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.