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 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.
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 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
