One of the very best words.
S
subversivo@app.wafrn.net
@subversivo@app.wafrn.net
Posts
-
This post did not contain any content. -
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.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.
-
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.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.