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 said:
>
> (e.g. it requires all IDs to be sortable lexicographically, despite having next/prev cursors),That's actually kinda a database performance thing: by having the IDs sortable by time, you can efficiently shard the database and maintain indexes. Same reason to prefer UUID v7 over v4, as v4 in databases can lead to hotspots
-
> @kopper@not-brain.d.on-t.work said:
>
> (e.g. it requires all IDs to be sortable lexicographically, despite having next/prev cursors),That's actually kinda a database performance thing: by having the IDs sortable by time, you can efficiently shard the database and maintain indexes. Same reason to prefer UUID v7 over v4, as v4 in databases can lead to hotspots
@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 -
@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@thisismissem if the cursor was opaque then mastodon could use a tuple of created_at and id as the cursor and would not need to back-date their snowflakes -
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") -
@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