“With targeted FEPs and pioneering implementations like Flowz, the Fediverse can break free of proprietary client APIs and monolithic client/server implementations and empower a new wave of social web innovation.”
This is such a valuable insight! There are 2 extremes in decentralised social app dev, one where an app is just a dumb terminal for a particular server, and then the inverse, pure P2P apps with no server. But there is a middle ground. Apps can be a focus of UX development, and access different servers as needed to provide functionality that’s impractical (if not impossible) to do with pure P2P networks.
Since @stevebate and I have butted heads here from time to time, I want to be crystal clear that this is not some kind of subtle ankle-tap, but genuine praise. Both for his experiments with Flows, and particularly the way the quoted piece expands on various issues with AP C2S.
Standard C2S API doesn't liberate clients from servers because everything is still tied to a single server. We may get more client diversity but not much more.
The middle ground between client-server model and P2P is FEP-ae97. It's C2S API combined with nomadic identity.
You seem to be conflating different topics here: client software versus actor identity mobility. The C2S API does not tie client software to a single server or a single server (instance or implementation) to a single client implementation.
The difference with C2S is that rather than using a non-ActivityPub, proprietary microblogging API developed by a specific project, this would be a standardized (AP+FEP), community-driven, relatively general-purpose API with a wider range of potential interop than just Mastodon and servers that have implemented the Mastodon client API in some form.
Sorry, whatever point you were trying to make wasn’t clear to me, so that was my best guess. Given my guess was clearly wrong, I still don’t understand how the “everything is still tied to a single server” claim was related to the topic of this thread? I’m interested, if you want to elaborate.
(These OT tangents should be addressed in a separate topic or toot-thread. We now have 4 off-topic comments in this discussion topic. This may be another fragmentation issue caused by federation to consider, where a forum has more moderation tools to prune community content. Though this was posted directly on-forum, I think)
Fair cop @aschrijver . I presumed that Steve would reply on the fediverse. I would have addresses him there directly, but I couldn’t find his social address. There doesn’t seem to be a contact page on his blog, and his account here has a hidden profile for some reason.
@strypey I was replying to the points you made in the original post, specifically:
There are 2 extremes in decentralised social app dev, one where an app is just a dumb terminal for a particular server, and then the inverse, pure P2P apps with no server.
When you use a "standard" ActivityPub client, your identity is still tied to a single server, and the data is tied to identity, so it doesn't make you closer to the second extreme (P2P apps with no server). ActivityPub C2S API is merely a different kind of client API. If its shortcomings are addressed, it might become an alternative to vendor-specific APIs, but overall it is not a big deal.
To move from dumb terminals towards p2p, a very different technological change is required.
As @stevebate said, that’s a totally separate issue. What I’m talking about is whether the client is tied to a single server type. Steve’s post tries to look beyond the server + web-client monolith, as a standard deployment model. It’s particularly looking beyond the vanity C2S API model that went with it until people started reverse engineering the API of the dominant server (StatusNet, then GNU social, then Mastodon). Please let me know if that distinction is now clear.
I’m sure it’s obvious that a standard C2S API used across the whole fediverse would allow people to pick apps and stick with them as they moved their homefeed around different servers. Even if it does require setting up a new account from scratch(1). But what I’m excited about is the idea that if someone started on Mastodon, then realised they wanted to post short video more than short text, they could set up a new account on Loops, and use it in the same general-purpose app. If the app could support multiple accounts, they could add their new Loops account to their app, and keep Mastodon there one too, just in case.
Again, I’m sure we all agree that pure AP C2S can’t do this, it’s underspecified, ie too flexible. But cloning of domain-specific APIs like Mastodon’s can’t either, they’re not flexible enough. Whereas an AP C2S judicially extended by FEPs could do it, which is what Steve’s blog piece is about, and what his Flowz client is experimenting with.
(1) I imagine we agree that it would be better if we didn’t need to create a new account, but could use nomadic identity and channel cloning to take our identity with us. But that’s orthogonal to this discussion.
I may bring an additional more top-down design perspective into consideration and to ideate on, but please let me know if that is better addressed in a separate topic.
What if we “Liberate people from clients, apps and servers”?
If the “fediverse facilitates online communication and social interaction between people”, then the ActivityPub protocol specifies how to implement an abstraction on top of servers and clients in order to provide “a distributed network of addressible actors for the exchange of social activities”. This abstraction no longer relies on the notion of servers and clients, though for certain social networking use cases you may opt to re-introduce them (.. but then they live as concepts in this higher level of abstraction).
Though conceptually the ActivityPub spec didn’t prescribe this, the dominant abstraction for “joining the fediverse” in the present day involves “select an app, select a server that hosts your app of choice, and use a client that supports that app, to access it”. In other words, currently fediverse offers a predominantly app-centric view of the world. But this need not be the only view that is supported, and I advocate a shift towards having a fediverse of mixed apps & services, and elaborate a service-oriented view e.g. as a compliant AP protocol extension.
In the service-oriented view - and in a paradigm shift towards app-free computing - there wouldn’t necessarily be “Instances” as we have today, but parties that are positioned as fediverse access providers. You can compare this to the telecom sector, providing the plug in your house to deliver TV, phone and internet services at your doorstep.
When relating that to a good software with ActivityPub C2S support, I can envision that people after gaining access and becoming fedizens, can easily discover, obtain and wire services together in interesting ways that support their social networking use cases and needs. And dynamic UI/UX that supports that, based on service configuration and protocol (control) data exchange.
As @stevebate said, that's a totally separate issue.
I was replying to your point about P2P, which doesn't seem separate. But if you don't want to talk about that, no problem. Let's switch:
look beyond the server + web-client monolith, as a standard deployment model
It is not a standard deployment model. Mobile clients are very popular, and they are not deployed together with a server. Some servers are deployed without a web client (e.g. GoToSocial). Some web clients are deployed separately from servers (e.g. Phanpy). Support for multiple backends is also common (many clients that work with Mastodon will also work with Pleroma and so on).
But what I'm excited about is the idea that if someone started on Mastodon, then realised they wanted to post short video more than short text, they could set up a new account on Loops, and use it in the same general-purpose app.
But cloning of domain-specific APIs like Mastodon's can't either, they're not flexible enough. Whereas an AP C2S judicially extended by FEPs could do it, which is what Steve's blog piece is about, and what his Flowz client is experimenting with.
If a certain feature can be implemented with ActivityPub C2S API, it also can be implemented with REST API. Because ActivityPub C2S API is just a different kind of JSON API, there is nothing magical about it, despite what is written in that blog.
A pure P2P app is the ultimate liberation of client from remote server, as it does away with the latter altogether.
… but they have to use the API dictated by the server. Often, but not always the one defined by Mastodon. So an app has to support multiple APIs to support all fediverse servers. I presume this makes it harder to combine services, and that this is why the limited PeerTube support in FediLab is curtained off from the rest of the UI.
Very few, and this is a relatively new development, and these too dictate a bespoke API apps must use, and be constrained by the limitations of. Even if it’s a frequently reused one (ie Mastodon’s), not their own.
I’m trying to start a conversation about the potential UX benefits of moving the ecosystem towards a standardised, multi-purpose C2S API. The benefits of this seem obvious to me, and Steve lays them out in his piece, so I won’t restate them here.
If this doesn’t interest you, that’s fine. If you think it’s a fools errand and we’re wasting our time, then why waste your own by splitting hairs about it? Just leave us to it, and focus your energies on discussions about things you do support.
Maybe we can create a list of interesting use cases and scenario’s that allows us to brainstorm all the various ways that clients and servers can interact, and then contrast a pure C2S approach vs. S2S + Proprietary client API, list pros and cons and challenges to overcome.
There is an existing forum category that is nearly unused, where we can post each use case as separate topics, with a wiki post at the top to collect insights from the discussion below it (or better, create wiki and discussion thread separately and cross-link, so they both get bumped on edits).
See Packaging category. We should ask if @decentral1se is okay with this repurposing, if there’s interest to elaborate things this way.
Magic is in having well-defined API’s that allow seamless exploration of our social web. 