洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

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 implementations is well-founded. Slapping an 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.

kopper :colon_three:'s avatar
kopper :colon_three:

@kopper@not-brain.d.on-t.work · Reply to 洪 民憙 (Hong Minhee) :nonbinary:'s post

@hongminhee yep, all you said is accurate, though i want to see if i can argue my case a bit clearly here
That's just the current architecture with the labels shifted
sure, underneath everything postgres and mastodon are already separate, but to the user's phone, web browser, or even other instances, they're only present as one unified blob under "Mastodon". my proposal is to make this split more explicit in the protocol level, especially when it comes to extensions (e.g. FEPs which try to add actor-global state for what are client needs, like feature negotiation)
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.
i think this is another consequence of the word "client" making everything confused. "mastodon clients" would still be "mastodon clients", they'd interact with the "mastodon c2s client" which understands mastodon specific concepts such as reply trees and timelines. i don't exactly believe, say, a forum frontend would want to interface with those mastodon concepts, especially not all of them. maybe reply trees could be shared somehow? but i don't believe that's something the protocol has to dictate. i certainly don't think a microblogging frontend would be useful with a forum backend

what the interoperability promise really seems to want, at its core, seems to be to reuse the same account between different interfaces. as it stands you can't really use lemmy from mastodon (you can, but it's hacky and fills your timeline with boosts and your app ends up tagging people which you either have to remove manually or end up looking like a sore thumb in the comments). this is the solution i see c2s aiming to solve, not "mastodon owns the microblogging concepts"

additionally: if the custom client API is built on activitypub concepts such as collections and the objects are hydrated dynamically, as i propose, the pieces would still be the same AP pieces. the as:Note would still be an as:Note. while this would not make it easy to point one app to another backend, it would make it easier to share code relating to features, and may open up to getting individual client behavior (e.g. whatever the equivalent of the Mastodon API would be) standardized as optional FEPs which any client that wants to clone mastodon/microblogging can implement/extend upon