Today @kopper@not-brain.d.on-t.work [shared a post][1] on the fediverse titled [*how to not regret c2s*][2], 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.
-
Today @kopper@not-brain.d.on-t.work 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
-
@kopper@not-brain.d.on-t.work Thanks for engaging with this—it helps me think it through more carefully.
Your point about making the split explicit at the protocol level is well taken. I can see how that matters especially for extensions: a lot of FEPs end up adding actor-global state for things that are really client concerns, and having a clearer boundary in the protocol might discourage that drift. That's a concrete benefit I hadn't fully appreciated.
On the interoperability question, I think I see where we differ. You're reframing the core promise of C2S as “reuse the same account across different interfaces,” whereas I'd been reading it as “connect any frontend to any server.” Those lead to quite different designs. I'm not sure which framing is more faithful to what C2S originally intended—maybe neither of us is wrong, and the spec was simply underspecified on this point.
That said, if account portability is the goal, I wonder whether C2S is really the right tool for it. FEP-ef61 and the Nomadic Identity approach both tackle that problem more directly, by making identifiers server-independent at the identity layer rather than standardizing the client–server protocol. It feels like a different layer of the problem altogether, and I'm not sure C2S can carry that weight on its own even with your proposed architecture.
The point about AP objects remaining AP objects through hydration is interesting though. I can see how that keeps the pieces composable even without a standardized client API. I'll have to think about that more.
-
@kopper@not-brain.d.on-t.work That's a fair point about the Mastodon API—the lexicographic ID requirement and the pagination assumptions are good concrete examples of how standardization quietly closes off design space in ways nobody intended.
I think this exchange has been useful for me in clarifying that we're probably starting from different premises about what C2S is for. If frontend portability isn't the goal, then the case against standardizing the client API makes a lot of sense. I just can't quite let go of the feeling that portability at that layer is what most people imagine when they hear “C2S”—though I'll admit the spec itself is ambiguous enough that neither of us is obviously wrong.
Anyway, thanks for taking the time to respond. Lots to think about.
-
@kopper@not-brain.d.on-t.work The composability angle is something I hadn't fully appreciated before—a standalone reply tree indexer that any client can query via
proxyUrlis a genuinely interesting pattern, and it's not something you'd get from just standardizing a monolithic client API.On
did:key, you're right that handing over a private key for autonomous server actions is a real problem, and the non-rotatability makes it worse. Though I'd frame that as a limitation ofdid:keyspecifically rather than portable identity as a concept—FEP-ef61 mentions other DID methods as candidates, and the broader space of approaches to server-independent identity isn't exhausted by any single proposal.But agreed that they're orthogonal and can coexist.
-
Today @kopper@not-brain.d.on-t.work 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@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.
-
> @kopper@not-brain.d.on-t.work said:
>
> (e.g. it requires all IDs to be sortable lexicographically, despite having next/prev cursors),That's actually kinda a database performance thing: by having the IDs sortable by time, you can efficiently shard the database and maintain indexes. Same reason to prefer UUID v7 over v4, as v4 in databases can lead to hotspots
-
Today @kopper@not-brain.d.on-t.work 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
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.
-
Today @kopper@not-brain.d.on-t.work 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 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).
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login