There is a lot of discussion happening in the background of our project here. We could not anticipate all of the challenges that we were going to face a few years ago. One of the reasons for this was because we had no idea what our choice of a platform would bring.
Specifically, we chose Lemmy as the software that we would use to launch our endeavor to attempt a safe space for marginalized persons online.
In the first year or so, this choice was completely successful for a very small number of users. And then we all experienced an enormous influx of users when Reddit announced/implemented their shutting down of third party apps.
Since then there has been a huge number of people that have joined the Beehaw project. This tsunami of users initiated technical problems, and otherwise, that we could not foresee.
Thankfully and fortunately, we have had a couple of incredibly knowledgeable persons that have swooped in to ’save the day’ and keep this site running.
Unfortunately, these persons will NOT be able to continue to support the Beehaw project much further. They have life commitments and other factors, including careers and family life, that will prevent them from contributing to our project in an ongoing fashion.
All that being said, Lemmy (the software that Beehaw runs on) development is incredibly slow and is riddled with problems that makes administration/moderation very painful.
Therefore, we are left with some options that may feel uncomfortable to us. For example, we may want to consider leaving the Fediverse for another software platform that does NOT include ActivityPub. To explain, Fediverse/ActivityPub are very positive concepts on the foundational level. However, the Beehaw project is struggling to include this because most of our moderation/content/ethos is being jeopardized from OTHER federated instances (i.e. it, mostly, is NOT coming from within our own Beehaw registered user base).
The aforementioned persons, that have ’swooped in to save the day’, have been discussing/working with us to come up with the best solutions that would enable the Beehaw project to continue while NOT needing incredibly experienced/technically adept persons around.
Right now, we are testing alternative software platforms and evaluating them based on everything that we want Beehaw to become in the future.
Thank you all for your continued support of the Beehaw project and entrusting us to make this happen.
No. The tools needed for successfully moderating Lemmy federated items, is severely lacking. The primary devs do not seem interested in making this area a priority either from their own efforts, or others submitting PRs for such. More moderators won't help when the ability to moderate isn't there.
Makes me wonder if a fork will happen in the future. Wonder if offerings will be much different a year from now, and if options like kbin will be more polished by then.
Everyone wants a fork. Nobody wants to be the fork.
We need a small group of motivated and skilled developers to get together and decide "we're doing this", and actually go beyond announcing an empty Git repo. (i.e. actually have some usable code to show for)
Dealing with a codebase as janky and large as Lemmy is unfortunately beyond my skillset, otherwise I'd love to get involved myself.
Rust and ORM makes changes incredibly slow and even recent editions like sanitizing for JavaScript exploits have been buggy.
Lemmy had one major thing that kbin and other apps did not have in 2023... a working API. And that happened to be what Reddit decided to start charging for in May. Kbin is right now adding an API, but it isn't compatible with Lemmy. Lemmy could also use a streamlined API, there is opportunity right now to make a combined Lemmy and kbin API since federation normalizes a lot of the features between the two. I hope people see this opportunity that is open right now and the one big strength.
I don't think an API is the thing that matters here. There are quite a lot of things you can't hack on with a client alone and actually needs server side support to function (actual moderation tooling is a prime example)
Also most APIs aren't "designed" per se and just expose the internal representations of the projects they're of. A "common" API would either be too "wide" enough to be unusable (hello, ActivityPub C2S) or would severely limit experimentation and innovation (good luck on building microblogs in the Lemmy API) without having so many extensions that essentially end up being a third, completely different API.
because of the negatives in your statement, it isn't clear what you mean.
I think the API is why June 2023 there was a huge surge of users coming to Beehaw and Lemmy platform. There were tons of forum software out there, and even kbin, but Lemmy took off because it had an API
fixed that part, words are hard
The thing I'm trying to say is that "having an API" does not matter in the long term if the API does not expose the functionality needed to use it properly.
And TBF if someone joined Lemmy only because it had an API and nothing else then they're gonna be in for a very rude awakening sooner or later as the troubles of federation that previous (mostly microblogging) platforms have encountered and attempted to solve (not to mention novel problems due to the community oriented nature of Lemmy) start to show up.
This is only going to get worse, and throwing "more API" into the fire won't fix any of the important problems at hand.
Your entirely reply seems to dismiss the entire purpose of an API.
An API is a way to allow other developers to work almost entirely independent, and even create compatible servers with wildly different implementation - while still servicing clients.
You seem to be advocating a model that predates API, back in the 1980's or something. As right now kbin users are having to resort to scraping content off off HTML pages as a form of API.
All fediverse code is weird. Lemmy is extra weird on account of being written in a systems language
Picking a fedi server software is just picking how much (and what kind of) jank you're willing to tolerate. The features are always secondary.
I don't think a fork would be a solution to this problem. The problem is not that the maintainers don't accept contributions, but that no one is making the necessary contributions.