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.
-
@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 -
@thisismissem oh I know, yeah. that said I do think having an opaque cursor value instead of requiring it to always be the id would be more flexible
I also believe this causes mastodon to have to manually build snowflakes based on remote post creation dates (which is as fragile as you expect and likely does not help b-trees since theyre no longer always correlated with insertion time), but unsure on that. I know misskey does for sure> @kopper@not-brain.d.on-t.work said:
>
> that said I do think having an opaque cursor value instead of requiring it to always be the id would be more flexibleFor pagination on the Collections? Yes, absolutely. However, for object identifiers stored in their database, that's an implementation choice. You can use any ID scheme you like.
-
@thisismissem to paginate the Mastodon API responses, effectively "hiding" max_id, min_id, and since_id behind an opaque token clients aren't supposed to parse. this should be irrelevant to AP collections since they already work this way (just with URLs instead of free-form strings)
-
yes, this should just be a cursor with a pagination direction. However, the Mastodon API is proprietary and specific to their needs so they can do whatever they want and whatever makes sense for their application.
I believe ActivityPub API just gives you URLs to follow for prev/next/first/last.
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