The Threadiverse is growing again, this time offering an effort to build a new Lemmy replacement from scratch, with API compatibility.

Seems like an interesting effort. A developer is building an alternative Java-based backend to Lemmy’s Rust-based one, with the goal of building in a handful of different features. The dev is looking at using this compatibility to migrate their instance over to the new platform, while allowing the community to use their apps of choice.

  • maegul (he/they)@lemmy.mlEnglish
    3·
    10 months ago

    So while there’s plenty of talk in here (even from the core lemmy devs) about how much it makes sense and how much value there is in starting a new project with a different tech stack that includes Java, compared to simply contributing back to the current project that has momentum … and while that’s an interesting and important conversation …

    Realistically, developers will make what they want to with what they want to (to a fault IMO, especially within the broader mission of the fediverse, but that’s besides the point). This project will happen, people will contribute and it may succeed.

    So, to focus on the positives and what can be made good about this …

    It’s great that there’s some sort of settling on a standard here and trying to be a “drop in replacement”. Continued commitments to consistency and interoperability would be awesome. While collaboration may be naturally limited, there’d still definitely be scope for it …

    • ideas and designs, obviously
    • Database management and optimisation, which is likely a big one.
      • On that … AFAICT, SL is using MySQL? Can’t help but wonder (without knowing the technical justifications here) whether it would make much more sense to stick with the same DB unless there’s a good reason for divergence.
    • Front ends and the API, another big one but one where the two projects could conceivably work together.

    I’m likely being very naive here, but I can see both projects coming under a single umbrella or compact which provide different backends and maybe DB setups or schemas but otherwise share a good amount in design and mission.

    However unlikely that is … trying not to fragment the fediverse too much would be awesome and its pleasant to see some dedication here to that end.

    • Blaze@discuss.onlineEnglish
      1·
      10 months ago

      whether it would make much more sense to stick with the same DB unless there’s a good reason for divergence.

      SL Dev said they reengineered the database schema and didn’t want to use the Lemmy one. Based on the summer performance issues, I guess it makes sense.

      However unlikely that is … trying not to fragment the fediverse too much would be awesome and its pleasant to see some dedication here to that end.

      At the end of the day, it’s still Activitypub. The compatibility between Lemmy and Kbin works pretty well, most of the issues we had were federation related, and those existed within Lemmy itself.

      • maegul (he/they)@lemmy.mlEnglish
        1·
        10 months ago

        Well there’s still the question of using MySQL (?) rather than postgresql, where all manner of expertise about the DB can be useful to share. Not sure what kbin uses, but pgsql is pretty common around the fediverse.

        And yea, it is all ActivityPub. I’m just not as faithful in that as others tend to be. It seems to be a fuzzy system that allows idiosyncrasies to creep in. Mastodon and Lemmy don’t get along too well and so sometimes AP just isn’t enough (I’ve just been trying to help someone whose masto instance seems not able to post to lemmy). At this moment, getting along is valuable for the platforms, for the fediverse and for us users.