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