Kabaka

Kabaka, 11 months ago

Other than the bare minimum to define some routes, the code for the API isn't written yet. Basically everything on this site is generated with server-side rendering and templating. It's PHP and looking at the code and design is like stepping into a time machine.

Kabaka, 11 months ago

there's nothing stopping anyone from making mobile apps are alternative web front-ends

The biggest thing stopping people is the fact that the API does not actually work. As far as I can tell, every API endpoint (slowly) returns:

{
    "@context": "/api/contexts/Error",
    "@type": "hydra:Error",
    "hydra:title": "An error occurred",
    "hydra:description": "Internal Server Error"
}

In order for anyone to build new clients, the API first needs to be finished. Unfortunately, the choice of using PHP/Symfony is going to hinder that due to its incredibly low popularity. I got my start in software engineering by professionally writing PHP, but I haven't touched it in at least 15 years.

I'm currently trying to find my way around kbin-core, and it is a mess. There are almost no comments (and some commented-out code with no explanation), huge amounts of what I assume are stubs, and the commit log is a nightmare (commit descriptions are meaningless and repeated, like four commits in a row with only "Post expand fix" as a description).

This needs a lot of work before anyone should start trying to build API integrations.

Kabaka, 11 months ago

they can just talk to each other directly

They directly talk to each other via an API. Even if you own all layers of an application like this (e.g., presentation layer, front-end APIs, back-end, etc.), each layer communicates via APIs. These may be private APIs that third parties cannot use, but they are still APIs. Even if it looks much different from the usual RESTful HTTP APIs we're used to, any other solution would still be considered an API.

Kabaka, 11 months ago

The errors from the API are because the API is not written. The routes (URLs) are defined, and some of them have a little code to generate responses, but the code is simply unfinished and does not yet work.

AFAIK, which isn't a whole lot kind you, the front end is using the API

The web UI is mostly generated server-side. Even user preferences are set by navigating to a URL rather than having some XHR/AJAX/etc. request handle it. This is still a sort of "API" but most of what is traditionally done by client-side JavaScript is handled within a monolithic PHP application.

So, no, the current web UI is not using the API in any sense you would expect.

Kabaka, 11 months ago (edited 11 months ago)

I would find it hard to actively support

I think regardless of personal views, the project is essentially tainted and should be avoided. Too many users will feel alienated by the controversy. I came to kbin because the lack of such controversy points to better viability for such a large community.

So where do you think kbin's best odds lie at the moment? Clone and rewrite it in a different language while it's still early or work with what's there? Get a couple of iterested devs together to do some brainstorming?

Rewriting it in a different language/framework was my first thought. Honestly, though, it is pretty large and I don't think I have the amount of time I would want to contribute to such a project. I might still make an attempt, but I agree that the best bet is to have a number of dedicated volunteers get together, plan something out, and execute as a team.

I also have real concerns about the architecture that was chosen. It is going to be really hard to scale this without just throwing a ton of money at it to horizontally scale [edit: or vertically scale, right now, since this doesn't seem to be ready for any kind of clustering] the entire app at once. It's just being operated as a single docker container running on a single VPS. This is just asking for trouble. The ecosystem with which it needs to integrate is mature enough that some reasonable optimizations can be made to keep performance good, especially around the federation APIs, clustering, and other separation of concerns.

Kabaka, 11 months ago

Yes, that's what it means. If you look under the names, you'll see "public" or "private." The way they are going offline is to make the subreddits private. The green ones are labeled private.

Kabaka, 11 months ago

Reddit limits how much negative karma users can receive per comment, but they don't limit positive karma. So once the negative limit was hit, the few upvotes he got were the only ones being counted.

Kabaka, 11 months ago

I think there is some confusion. Lemmy.ml is itself an instance. Hosting your own means not using lemmy.ml.

Kabaka, 11 months ago

Yes, and I'm interacting via something else as well. However, communities are tied to individual instances. For example, a user could post to photography@lemmy.ml and we could all participate, but lemmy.ml is responsible for the community and its contents. If lemmy.ml goes away, so does that community, etc.

This comment thread and portions of the post are about which instance should host a community. Maybe you are confusing the Lemmy project with lemmy.ml.

Kabaka, 1 year ago

There are many instances ("servers") of the service running, and each one can have its own, local equivalent of a subreddit. We can see and interact with all of them. I just went through 15 pages of "magazines" and subscribed to communities with the same name on 2+ instances at least a dozen times.

Suppose I am interested in photography, so I subscribe to the photography community on instance "foo." Another user has the same interest, but they find the community on instance "bar" and subscribe to that. If I post on photography@foo, they won't see it. The community is effectively split — often into more than two parts.

This makes it really difficult to build an engaging community at a scale similar to Reddit's. Ideally, users will eventually congregate around just a few, but this is going to make early growth quite painful. And it isn't intuitive to newcomers.

Kabaka, 1 year ago

I don't think the problem is limited to "morons." I understand this system and have operated federated services in the past, but it is a lot more work just to navigate this when compared to something like Reddit. I don't have a ton of free time, and I'd rather spend that time engaging with the community vs wrestling with the service or trying to find which instance has the most activity. I know this will get better as it grows, but a lot of people will just get fed up and go somewhere they can just socialize.

Kabaka, 1 year ago (edited 1 year ago)

That would be cool, but he's been pretty clear that it is going to be the end of Apollo. It's a very complex application with a Reddit-specific backend service and lots of other assumptions that would just not work here. Maybe some of the UI/UX could be reused, but it would probably be easier to recreate it from scratch than to adapt the existing app.

Kabaka, 1 year ago

Because of how fragmented this platform is, there isn't a universal answer. Some links will work in one client but not another. Fixing this will require a lot more coordination than is currently happening.