dansup
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
Gregory
@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
@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.
Evan Prodromou
@grishka @dansup that's a known issue! Good one to bring up.
Gregory
@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.
dansup
@grishka right??? Glad you get it and am glad my provider doesn’t block Russia because like how does censorship help the people? The people aren’t in charge, so why take it out on them.
Gregory
@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.
Gregory
@dansup ask the mstdn.ca admin about that, he thinks him blocking countries is noble or something
Evan Prodromou
@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, signatures and storage to the back end.
silverpill
>I can imagine a "minimal" server that implements c2s but almost no UX of its own though.
AKA generic ActivityPub server:
https://codeberg.org/fediverse/fep/src/branch/main/fep/fc48/fep-fc48.md
I think it's a cool concept, but nobody knows how well it will work in practice.
infinite love ⴳ
@dansup mastodon and loops are the activitypub clients here. they can still expose their own apis for mobile phones to use.
the duplicate logic is when mastodon and loops have to each handle delivery on their own, instead of being able to use a shared delivery server.
it's kinda like saying you don't need a database, because everyone can just implement their own database. where would mastodon and loops be if postgresql didn't exist?
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.