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.
-
@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.
-
R relay@relay.mycrowd.ca shared this topic
-
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.
Protosocial ActivityPub protocol
Protosocial ActivityPub v1.0.0 Pro-social protocol suite for the social web, based on ActivityPub Protosocial ActivityPub protocol is an extension of W3C ActivityPub that focuses on ease of use for the developm…
Discuss Social Coding (discuss.coding.social)
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.
Protosocial ActivityPub protocol
Protosocial ActivityPub v1.0.0 Pro-social protocol suite for the social web, based on ActivityPub Protosocial ActivityPub protocol is an extension of W3C ActivityPub that focuses on ease of use for the developm…
Discuss Social Coding (discuss.coding.social)
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 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.
-
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. -
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.@subversivo @hongminheePersons, Pages, Groups, Notes, Posts, Events and an ever-growing resource list
and an ever-growing scope. every time someone tries something new on the fediverse you now have to manually support it to be compatible. i don't believe anyone would want to take on such an effort.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.
replace "plugin" with "client" and this is pretty much the same thing i'm arguing for. i think you're getting confused by how the word "client" is used here (it does not mean "the part that runs on the user's device") -
R relay@relay.mycrowd.ca shared this topic
-
@subversivo @hongminhee
Persons, Pages, Groups, Notes, Posts, Events and an ever-growing resource list
and an ever-growing scope. every time someone tries something new on the fediverse you now have to manually support it to be compatible. i don't believe anyone would want to take on such an effort.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.
replace "plugin" with "client" and this is pretty much the same thing i'm arguing for. i think you're getting confused by how the word "client" is used here (it does not mean "the part that runs on the user's device")Yes, no one would want to maintain a behemoth. I think this is the main reason it don't exist.
But I fail to see the advantage of adding a layer of C2S inside the server, because there is no interoperability needs. What, says, Mastodon, gains by adding a C2S layer between their S2S layer and their Mastodon API layer? The example about emoji reactions… It needs to receive and store unknown AS2 activities, instead of dropping it, and interpret on the client/plugin layer, but this is achievable with DB schema and activity processing changes, not requiring unified protocol. All changes are internal.
-
Yes, no one would want to maintain a behemoth. I think this is the main reason it don't exist.
But I fail to see the advantage of adding a layer of C2S inside the server, because there is no interoperability needs. What, says, Mastodon, gains by adding a C2S layer between their S2S layer and their Mastodon API layer? The example about emoji reactions… It needs to receive and store unknown AS2 activities, instead of dropping it, and interpret on the client/plugin layer, but this is achievable with DB schema and activity processing changes, not requiring unified protocol. All changes are internal.
@subversivo @hongminhee i don't think you understood the goal here.What, says, Mastodon, gains by adding a C2S layer between their S2S layer and their Mastodon API layer?
in this architecture, Mastodon itself would be a C2S client that talks C2S to another server and exposes a Mastodon API for it's own apps. the part that stores and serves user data would be split off Mastodon into another server
