I’m reading the ActivityPub spec here and it seems pretty fit for client-to-server communications. Yeah, it might be somewhat bulkier than your typical rest api, but it’s more universal, which begs the question: why do mastodon and lemmy both decided to implement custom (and incompatible) APIs for their clients to talk to the servers? Wouldn’t it be more straightforward if e.g. my voyager app talked ActivityPub to lemmy.world which then talked ActivityPub to lemmy.ml or something.
What am I missing?
It could probably work but would quickly turn into a mess of custom extensions.
For example, ActivityPub has no concept of sorting by hot or active or new. ActivityPub also doesn’t specify how a client would authenticate to a server to post on your behalf. There’s definitely no ActivityPub message for registering a user account.
So it makes sense that S2S only does the bare minimum for the purpose of federation of content, while instances with varying implementations can implement whatever C2S protocol makes the most sense.
For example, should ActivityPub expose a Lemmy post as a nested thread, or a Mastodon microblogging-like format and let the clients reassemble the thread? How should a Mastodon client present a Lemmy community and threads? How about a Lemmy client connecting to a Mastodon server?
If we put that in ActivityPub, you’re pretty much bound to supporting it forever because other servers will eventually expect those protocol extensions, whereas it’s much safer to change a C2S protocol.
Keeping the ActivityPub simple has a lot of benefits if we don’t want the fediverse to remain really interoperable. A Lemmy client can reasonably expect that a given server supports a given set of features, providing a much more reliable experience than basically spaguetti of supporting every possible features and presenting the data weirdly.
Postel’s Law is relevant here. Conservative in what you send (simplify the schema of the data on the wire) and liberal in what you receive (put the complexity for interpreting that data in the client).
The underlying assumption is that we need to have separate applications. Why is that? Why can’t the client define how to present/ sort/act on the data?
In that case, why don’t everyone just use a generic fediverse server and let the clients make it into Mastodon/Lemmy/Kbin/Pixelfed/Friendica/Firefish/PeerTube/whatever else?
The reason is all those server implementations work differently, have different features, different goals, even different cultures and etiquette, or even just for the heck of it. That’s the point of the fediverse, it’s interoperable but you’re also not limited by one single standard as to how you want to expand. Lets say we settle for Mastodon’s implementation. Cool, now people want downvotes. Mastodon doesn’t do downvotes, but it’s the reference implementation. You can’t have downvotes, you’ll never have downvotes unless you convince everyone to implement downvotes. Nobody will want to make a server that does everything. Maybe the Mastodon guys don’t want to implement downvotes because it promotes negativity and they’d rather posts just stay at zero likes. Maybe a site is implementing an additional score for funny/serious. What do we do, do we just allow clients to include any data they want?
Even if it worked that way, eventually, people would still make servers with proprietary UIs and proprietary features and APIs. You just can’t stop it, developers gonna develop.
Also, if every client supported every format, it would be a nightmare to make clients. And still, there would always be clients with different takes on how to present the data anyway, because again, developers gonna develop. People get creative and do their own thing, and it’s how cool stuff gets born.
If you make a rigid spec outlining every possible feature, then you need a group of people to decide what the spec is, and eventually, people are gonna get tired and make an entirely different protocol anyway, but this time it may not be interoperable.
You’re always gonna end up with specialized servers, and matching specialized clients.
If you want to make a superserver and superclient that supports everything, go ahead and make one. It may take off, it may not.
Ultimately, the fediverse will grow organically, custom implementations will happen if not only for personal toys, because there’s no governing body making a hard spec. And it’s a good thing for things to have a chance to last, or inenevitably there will be disagreements and lead to forks.
How is pushing for a single megaimplementation a good thing?
why don’t everyone just use a generic fediverse server and let the clients make it into Mastodon/Lemmy/Kbin/Pixelfed/Friendica/Firefish/PeerTube/whatever else?
Yeah, I’d love that!
That’s the point of the fediverse, it’s interoperable but you’re also not limited by one single standard as to how you want to expand.
Just like the world wide web has always worked, and we managed to get by with only one single client (the web browser)?
Lets say we settle for Mastodon’s implementation.
Then we’d be off by a really bad start, because Mastodon does not implement a lot of the ActivityPub standard and hides a bunch of functionality under their own API?
If you make a rigid spec outlining every possible feature, then you need a group of people to decide what the spec is
Maybe we are talking about different layers of the OSI model, but the spec I’m concerned about already exists.
If you want to make a superserver and superclient
No, there is no need for a “superserver”. Other than storing messages, the server doesn’t really need to do much. Everything else can be done by the clients. There is also no need for a “superclient”, we can have different clients doing different things depending on what we want.
My point is that I don’t mind have separate “lemmy” and “mastodon” clients to have the respective “link sharing” and “microblogging” applications, but I do mind the fact that I need to register two separate accounts and two separate actor identities to do it, because currently these applications are providing functionality on the server-side that could (should?) be on the client.
My assumption would be that, yes Lemmy, Kbin and Mastodon use the same underlying communication protocol called ActivityPub but those have some additions which make their whole featureset incompatible to each other. So instead of writing a combined super Fediverse Browser/Explorer/whatever you get specialised Applications for Lemmy/Kbin and Mastodon.
C2S leaves a lot of things open and isn’t documented the greatest. It also doesn’t really provide many of the features people expect, leaving it all up to the client to provide a comfortable experience.
In theory this isn’t a problem. The Lemmy frontend could just be an abstraction layer over the AP server, providing a web interface for all of its features. Apps could also implement threads and such on any C2S capable server if they agree with each other how things like voting works.
However, that is all incredibly I efficient. Though Mastodon and Lemmy have purpose-built databases, they still run into performance issues. A basic ActivityPub server would be absolutely terrible for performance when you have a decent amount of users.
There are a few C2S clients, but no pure C2S servers that you can just set up and use. With some extensions, I can see C2S becoming more relevant, but as it stands right now, it’s just not a friendly protocol to develop against. I tried, and I couldn’t even find a good reference for how to do authentication from the client (there was a mention of OAuth but very little details) and I couldn’t find anything that offered a plain and simple C2S API.
I wouldn’t quite call Lemmy’s protocol much friendly either. I’m trying to implement it and it’s a bit of a mess, honestly. There’s absolutely no documentation, private database specifics leaking into the public interfaces, and an absolutely horrendous authentication scheme.
You’re not wrong, Lemmy’s API is rather crudely documented. It’s not 1.0 yet and they have plenty of funding related milestones to hit before the end of the year, so they have good reason not to invest too much time, but the Lemmy API certainly needs some docs.
Alternatives on the Fediverse (Mastodon/Calckey/Akkoma/etc.) all have much better API docs. Lemmy and Kbin are relatively unfinished and unfortunately that comes with all the downsides.
However, Lemmy has an SDK available (that you may need to generate). The ActivityPub C2S API has gems like:
Unfortunately at the time of standardization, there are no strongly agreed upon mechanisms for authentication. Some possible directions for authentication are laid out in the Social Web Community Group Authentication and Authorization best practices report.
Servers MAY support uploading document types to be referenced in activites, such as images, video or other binary data, but the precise mechanism is out of scope for this version of ActivityPub. The Social Web Community Group is refining the protocol in the ActivityPub Media Upload report.
“How do I log in” and “how do I upload an image” isn’t specified by the C2S API at all. All you have is suggestions. That makes the entire protocol kind of useless to implement in its current state. You can pick a backend implementation you like and write your application for that, but that does come at the cost of breaking all other clients.
There are a few C2S implementations. You can use Pleroma and forks or Fedbox together with a client like Andstatus if you want to use C2S. The main design of AndStatus is oriented around Twitter/Mastodon more than anything, but it does allow reading threaded comments (like on Lemmy).
