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
-
? Guest crossposted this topic to General Discussion
-
T tag-activitypub@relay.fedi.buzz shared this topic
-
@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 -
@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@hongminhee additionally: the Mastodon API already has some interesting limitations it imposes upon people implementing it (e.g. it requires all IDs to be sortable lexicographically, despite having next/prev cursors), and many apps impose additional undocumented requirements on top built from assumptions Mastodon the software makes that Mastodon the API documentation does not promise.
this puts several restrictions on features implementations are unable to expose over the mastodon API, such as non-chronological timelines (clients using the Link headers could use these, but pagination with manually building max_id min_id queries could not). standardizing client-level APIs would only bring similar restrictions but now at a layer where novel features now involve dealing with messy and slow standardization work to unblock, or end up partially implementing the standard so existing apps have to special case you anyway -
@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@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.
-
@hongminhee additionally: the Mastodon API already has some interesting limitations it imposes upon people implementing it (e.g. it requires all IDs to be sortable lexicographically, despite having next/prev cursors), and many apps impose additional undocumented requirements on top built from assumptions Mastodon the software makes that Mastodon the API documentation does not promise.
this puts several restrictions on features implementations are unable to expose over the mastodon API, such as non-chronological timelines (clients using the Link headers could use these, but pagination with manually building max_id min_id queries could not). standardizing client-level APIs would only bring similar restrictions but now at a layer where novel features now involve dealing with messy and slow standardization work to unblock, or end up partially implementing the standard so existing apps have to special case you anyway@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.
-
@hongminhee nomadic identity is interesting but orthogonal to this i believe. the advantage of my approach to c2s is that it lets you use different interfaces at the same time (which admitted nomadic identity can also do if implemented correctly), and also lets you create frontends which can combine multiple backends together (e.g. a standalone "reply tree indexing client" that any app that wants reply trees can call to via as:proxyUrl, apps that use a "c2s mastodon api" but also have a separate "emoji reaction indexing client" they can query to add features on top of the other api they're built for)
i have additional thoughts around nomadic identity as it currently exists (e.g. as far as i can tell did:key is unusable as you have to give your private key to the server for it to do autonomous actions such as approving follows automatically, and since the key can not be rotated the server can now permanently impersonate you for the future), but they're not relevant to this and both nomadic identity and c2s can be done at the same time -
I've been on the same subject the past week, making these arguments. I'd love to see protocol separated from solution design. Most recent additions to the fragmentiverse.. https://social.coop/@smallcircles/116144360830436951
-
@hongminhee nomadic identity is interesting but orthogonal to this i believe. the advantage of my approach to c2s is that it lets you use different interfaces at the same time (which admitted nomadic identity can also do if implemented correctly), and also lets you create frontends which can combine multiple backends together (e.g. a standalone "reply tree indexing client" that any app that wants reply trees can call to via as:proxyUrl, apps that use a "c2s mastodon api" but also have a separate "emoji reaction indexing client" they can query to add features on top of the other api they're built for)
i have additional thoughts around nomadic identity as it currently exists (e.g. as far as i can tell did:key is unusable as you have to give your private key to the server for it to do autonomous actions such as approving follows automatically, and since the key can not be rotated the server can now permanently impersonate you for the future), but they're not relevant to this and both nomadic identity and c2s can be done at the same time@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 proxyUrl is 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.
-
I've been on the same subject the past week, making these arguments. I'd love to see protocol separated from solution design. Most recent additions to the fragmentiverse.. https://social.coop/@smallcircles/116144360830436951
PS. Protosocial mentioned in my toots has a public thread here. The forum is a note-taking tool, and elaboration - when I have the opportunity - happens in commons-only areas.
https://discuss.coding.social/t/protosocial-activitypub-protocol/665
Elaborated discussion started in Common social groundwork chatroom here: https://matrix.to/#/!xfLXShcTEkELTDxuTq:matrix.org/%24WgZaVOd4pC_EYbr2ZNWPSZDSEYM06hPTyyQS7yar1bM?via=matrix.org&via=d3v0.me&via=ellis.link
-
PS. Protosocial mentioned in my toots has a public thread here. The forum is a note-taking tool, and elaboration - when I have the opportunity - happens in commons-only areas.
https://discuss.coding.social/t/protosocial-activitypub-protocol/665
Elaborated discussion started in Common social groundwork chatroom here: https://matrix.to/#/!xfLXShcTEkELTDxuTq:matrix.org/%24WgZaVOd4pC_EYbr2ZNWPSZDSEYM06hPTyyQS7yar1bM?via=matrix.org&via=d3v0.me&via=ellis.link
This thread, in particular the starting post, are direction to move towards. We know this for years. Somehow there's a deep inertia to correct course. This "somehow" is the area of applied research that Social experience design focuses on and intends to provide solutions for: the very particular social dynamics that exist in grassroots environment, such as the FOSS movement and fediverse.
-
This thread, in particular the starting post, are direction to move towards. We know this for years. Somehow there's a deep inertia to correct course. This "somehow" is the area of applied research that Social experience design focuses on and intends to provide solutions for: the very particular social dynamics that exist in grassroots environment, such as the FOSS movement and fediverse.
SX defines the concept of a Grassroots open standard, and a domain of Grassroots standardization.
These are direly needed to be able to healthily evolve #ActivityPub to where it can be the future of social networking, and support a peopleverse.
-
@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 @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
!@movim @hongminhee i mean, this architecture isn't anything novel by any means, pretty sure atproto works this way as well and i have no reason to believe xmpp is any different. activitypub just got dealt very bad hand by:
a) the specs being incomplete and rushed out the door due to vague w3c politics i do not understand
b) mastodon only implementing them partially, where i assume their heritage as an OStatus (?) implementation played a role (switching federation protocols or implementing multiple protocols is significantly easier when your internal representation does not depend on it, and the way they're using AP, it still doesn't. C2S would fundamentally change that by locking the source-of-truth to AP. i did talk a little bit about this on a separate thread i've quoted below)
RE: not-brain.d.on-t.work/notes/aj9lpuwdc0bwvrf4 -
@movim @hongminhee i mean, this architecture isn't anything novel by any means, pretty sure atproto works this way as well and i have no reason to believe xmpp is any different. activitypub just got dealt very bad hand by:
a) the specs being incomplete and rushed out the door due to vague w3c politics i do not understand
b) mastodon only implementing them partially, where i assume their heritage as an OStatus (?) implementation played a role (switching federation protocols or implementing multiple protocols is significantly easier when your internal representation does not depend on it, and the way they're using AP, it still doesn't. C2S would fundamentally change that by locking the source-of-truth to AP. i did talk a little bit about this on a separate thread i've quoted below)
RE: not-brain.d.on-t.work/notes/aj9lpuwdc0bwvrf4@hongminhee @movim that said, i'm not that hopeful for xmpp-as-social-media given AP already has better momentum than most (only really exceeded by atproto?) and an instance migrating to C2S does not disrupt their access to the non-C2S AP network the same way moving to XMPP without a bridge or AP nomadic identity would (the initial migration would require the actor ID to change, with something like a as:Move migration)
that said, there is an opening in the Federated Discord Replacement area where i think XMPP can slot in extremely well if the user experience can be done right. the architecture of one space always being in one "instance" solves a lot of the jank alternatives like Matrix suffer from. i also did a thread on that (quoted) if you're wondering about what i feel is missing there. that said, i think y'all (movim) are doing a great job working on that already
RE: not-brain.d.on-t.work/notes/ailzlw7e50r9jgpy -
> @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.
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