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.
  • @bobtreehugger
    link
    English
    58 months ago

    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.

    • @selfOPMA
      link
      78 months ago

      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.

      • David GerardA
        link
        English
        58 months ago

        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

      • @bobtreehugger
        link
        English
        58 months ago

        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.

    • @bobtreehugger
      link
      English
      5
      edit-2
      8 months ago

      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.

      • @bobtreehugger
        link
        English
        58 months ago

        oh god, they put all the structs in the same file and all the impl’s in different ones. Why?

        • @selfOPMA
          link
          58 months ago

          it’s entirely possible they assumed C++’s compilation model applies to Rust

        • @froztbyte
          link
          English
          48 months ago

          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.

        • @selfOPMA
          link
          38 months ago

          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