Post
When it comes to ActivityPub c2s (client-to-server), I understand why it's unpopular and not widely supported.
Mastodon and Loops have wildly different APIs, and it would make no sense to try to adapt c2s for these platforms because then you have to duplicate validation and other logic, and for what?
The 2 people who actually use this?
A unified ActivityPub API for s2s would only work if every implementation handled every schema the same way, and again, difficult to get done.
s2s for the win
@dansup hey, Dan. I look forward to proving you wrong!
You have spent a lot of time building fit-for-purpose integrated servers from the network layer to the UI.
But not everyone can be a Dan Supernault.
The ActivityPub API lets us split the creative app interface from a reliable and secure transport layer.
So people can make cool social apps fast that do interesting things, and leave the heavy lifting of queues, login, signatures and storage to a dedicated back end.
This is also how I always understood C2S / ActivityPub API. Not as a universal UI client that somehow is able to deal with anything that is thrown at it. Or in the email analogy, an email client that understands any email.
But indeed as a separation layer between robust protocol and the solutions that are developed on top of them, that the protocol implementation allows direct focus on.
Social experience design defines social networking as "any direct or indirect human interaction between people".
That maps well onto ActivityPub: A social graph of addressible actors that exchange activities with an object payload.
If I look at that from the perspective of a 'Solution developer' I shouldn't even have to know (necessarily) about client vs. server in the conceptual design of my social web solution. I do actor to actor message exchange according to my solution's msg-based API's.
@dansup This all makes sense, but RE: "The 2 people who actually use this", this is why we have so many more tools and apps and browser extensions for Mastodon instead of all of the fediverse.
Well, to step back a bit, just handling logging into your home server is a pain.
At least that should work across all platforms, if I just want to verify a user without even needing to use their server's/platform's API.
This is one nice thing about the Atmosphere/ATProto. You log into your PDS and you have some shared core APIs, even if different apps have different lexicons or whatever.
So, while I get the challenges, I am still hoping for some unified APIs/authentication to do basic things like logging in and fetching profile details and posts.
@dansup And, sorry, just to really drive the point home, I was looking into how to open a fediverse account on one's home server, since we're still waiting for a native way to do this in the browser.
This is...awful.
@dansup Note the commented out path for Lemmy. This should work according to some old docs.
And it just doesn't, adding to the mess.
@dansup c2s is simply impractical, too. Both on the client and on the server.
On the server, you have to merge two disparate streams (feed and notifications) into one inbox.
On the client, you have to split them back apart. You also have to load a lot of non-optimized stuff from different servers. You just have to make lots of requests to do simple things, and now imagine all that on 2G.
I can imagine a "minimal" server that implements c2s but almost no UX of its own though.
@dansup also there's Russia where a third of the internet is blocked by the government, another third blocks Russian IPs from their side, and only the remaining part is freely accessible without any circumvention. Some servers also want signed GET requests. All this, again, makes it preferable to have a single server which acts as your gateway to the fediverse.
@grishka exactly. this guy ActivityPubs.
I do think there could be a very performant c2s type project, but it would have to ether depend on client rendering, or somehow include opinionated yet compatible html rendering for every type of activity and side effect.
It's kinda gross how c2s purists think they can just have everything, without thinking about every detail that affects every specific activity and the disparate contexts each implementation assumes.
@dansup well you can have an email-like inbox that just shows you activities your actor has received. For a proper UX you would need a c2s client that would turn these into something more meaningful. That's what I meant by a minimal server.
Install bonfire.cafe
Get the full app experience
