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