After the (temporary) defederation announcement of earlier i checked the Lemmy repo to see if there was already a ticket on the federation limiting option like Mastodon’s that people mentioned Lemmy doesn’t yet have. Not only i didn’t find it, i also saw that there’s about 200+ open tickets of variable importance. Also saw that it’s maintained mostly by the two main devs, the difference in commits between them and even the next contributors is vast. This is normal and in other circumstances it’d grow organically, but considering the huge influx of users lately, which will likely take months to slow down, they just don’t have the same time to invest on this, and many things risk being neglected. I’m a sysadmin, haven’t coded anything big in at least a decade and a half beyond small helper scripts in Bash or Python, and haven’t ever touched Rust, so can’t help there, but maybe some of you Rust aficionados can give some time to help essentially all of Lemmy. The same can be said of Kbin of course, although that’s PHP, and there is exacerbated by it being just the single dev.

  • Magzter@kbin.social
    link
    fedilink
    arrow-up
    4
    ·
    1 年前

    Just really needs some time invested in a docker compose solution, can easily spin up a dev env even with PHP.

    • VerifiablyMrWonka@kbin.social
      link
      fedilink
      arrow-up
      3
      ·
      1 年前

      It has one. Minus an undocumented step (that’s sat fixed in a pr). Bringing it up amounts to 4 lines in a console; 1 to bring up the stack and 3 to start a JS watch for asset compilation.

      • CoderKat@kbin.social
        link
        fedilink
        arrow-up
        1
        ·
        1 年前

        How did you find the config file setup? That was where I looked at the file and decided “ah, I don’t wanna deal with this”. I just wanted to test what I expected to be an easy fix. If the code in question had unit tests, I would have just used those, but I didn’t see tests. Actually, now that I think about it, I’m used to test files living alongside dev files, as is the Go convention, but maybe it’s like the Java convention with tests being in a mirror folder tree. I should check later.

        • VerifiablyMrWonka@kbin.social
          link
          fedilink
          arrow-up
          3
          ·
          edit-2
          1 年前

          There are tests (and if the readme is to be believed a 71% coverage) they live in the top level tests/ folder.

          As to the .env file you just need to rename the example one and either amend these values (with appropriate urls)

          SERVER_NAME=localhost
          KBIN_DOMAIN=localhost:9443
          KBIN_STORAGE_URL=https://localhost:9443/media
          
          MERCURE_URL=https://localhost:9443/.well-known/mercure
          MERCURE_PUBLIC_URL=https://localhost:9443/.well-known/mercure
          CADDY_MERCURE_URL=https://localhost:9443/.well-known/mercure
          
          

          Or add them to a new .env.local file.

          Start it all up and jobs done*

          *well, you need to run the asset pipeline and add an admin user but that’s all in the Readme.