Today @kopper shared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.

The author's frustration with naïve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you much—you end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The “JSON-LD flavored Mastodon API” framing is apt.

The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate “client” layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.

But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:

• C2S server ≈ a database (PostgreSQL, say)
• “Client” ≈ an application server (Mastodon, Misskey)
• “Frontend” ≈ the actual client app on your phone

That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the “client” layer—the bottom boundary.

The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: “we don't really need a standardized api,” they write, leaving each client free to expose whatever API it likes.

Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2S—log in to any server with any app—isn't actually delivered. It's been pushed one layer down, out of reach of the end user.

There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.

#fedidev #fediverse

@hongminhee @kopper You're maybe looking for something like the XMPP architecture in the end, where all the "Frontends" are clients in XMPP and everything else if fully standardized (C2S and S2S) ?

The "Movim API" is just XMPP in the end https://xmpp.org/extensions/ ✨

Social publications are standardized there https://xmpp.org/extensions/xep-0472.html, and we even have Stories https://xmpp.org/extensions/xep-0501.html 😸!

@hongminhee@hollo.social said

The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate “client” layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.

This is exactly what I say in the talk that I still need to record, and why I was working on that ActivityPDS concept last september.

Maybe what we need is some sort of universal AP server, handling S2S, with support for all things (Persons, Pages, Groups, Notes, Posts, Events and an ever-growing resource list) where you can add one or more application APIs/Frontends as some sort of plugin. Say you import Mastodon-API module that uses a subset of server capabilities serve to Mastodon apps. Or a Lemmy-API that uses another subset. Even a C2S API that have all the business logic on the client side.
I think a C2S universal protocol is addressing thee wrong problem. C2S have less value than a universal server implementation that can work almost like a black box, not bound to a single client API because APIs are the easier part of the stack.

yes, this should just be a cursor with a pagination direction. However, the Mastodon API is proprietary and specific to their needs so they can do whatever they want and whatever makes sense for their application.

I believe ActivityPub API just gives you URLs to follow for prev/next/first/last.

@hongminhee > Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you much ...

The benefit of having a C2S adapter for Mastodon is that it provides a large user pool that could motivate developers to create C2S UIs rather than only supporting the Mastodon API. Having more server-independent client implementations may motivate devs to build general C2S servers with advanced features and eventually disrupt the Mastodon dominance in the Fedi.

@hongminhee @kopper
The mistaken conflating assumption developers keep making is equating engineering 4 human interface & interaction (with data) design is with the same approach as servers interacting with API and response payloads.
APIs don’t need 2D layout geometry simulating 3D, animations optimized for human eyesight variations, content (data) presentation optimized for human cognitive and literacy variations, etc.

Presentation on “APIs as osmotic interfaces”- https://mastodon.social/@dahukanna/115934845706354562

@hongminhee @kopper I'm too stupid to understand AP specifically (but I have a deep CS background).. I've always wondered why this wasn't the model by default? Using UUIDv7 you could mark every in order of timetime.

I think you could push the separation of intents further. Make a "AP post" hold all of the metadata, but make the actual text an attachment like an image, video, audio etc.. then you could just store all of the text in blobs in storage to be easily replicated/mirrored and deleted on bulk... "even as ciphertext" requiring the original toot to fetch and decrypt.

also. I think the idea of attaching a user to an instance (domain) was always a mistake. A user should be whoever owns the key material on a frontend (endpoint), and it should be able to ask any "client in your meaning" to be it's new primary location (they can be AP broadcast... user with public key X is now defaulting to client Y)...

BUT all of this is fan fiction, nobody has even solved the storage problem. We're still defaulting to 10,000 S3 buckets.

Turning media URIs from dedicated single URLS to magnet:<hashes> that can be pulled down from multiple locations incase the original dies feels like REALLLLLY low hanging fruit that nobody has touched (and It kind of annoys me nobody has).