As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.

[Guest]

@chrastecky @hugh

Thanks for writing this article! I tooted about it:

small circle 🕊 in calmness (@smallcircles@social.coop)

#ActivityPub "The Good, the Bad and the Ugly" is a good article by @dominik@chrastecky.dev https://chrastecky.dev/technology/activity-pub-the-good-the-bad-and-the-ugly The two mentioned examples in "The Bad" are long-time issues that were also discussed at #SocialHub. I just responded to one of them on the forum.. The #Mastodon Update(Note) quirk. https://socialhub.activitypub.rocks/t/update-note-quirk/4545/14 The other one is around Direct Messages which are a hack (a Note with special sauce). #LitePub specifies ChatMessage object type here, which is the intended way to extend the protocol. #FEP

social.coop (social.coop)

And it was good opportunity to follow-up on two #SocialHub threads relating to your examples in "The Bad":

Exposing edit history via Activitystreams

Per expose edit history in ActivityPub representation · Issue #23292 · mastodon/mastodon · GitHub @Johann150 raises a feature request for being able to view earlier versions of an activity or object before an Update was…

SocialHub (socialhub.activitypub.rocks)

`Update(Note)` quirk

Today I tagged the v4.0.0-beta.2 release purely to fix a single issue — Update(Note) federation. It turns out that just sending the Update(Note) activity was not enough, the underlying object needed to also have the upd…

SocialHub (socialhub.activitypub.rocks)

Distinguish between posts and direct messages

Hi, ActivityPub seems to be mainly focused on posts, but some applications also make it possible to send direct messages, which I also want to make possible in my own application. Unfortunately posts and direct message…

SocialHub (socialhub.activitypub.rocks)

[Guest]

@cascode @hugh gargron's perspectives are still accurate and gives a good (partial) list of the many underdefined aspects of C2S. Related discussion at SocialHub: https://socialhub.activitypub.rocks/t/nextgen-activitypub-social-api/4733/4

[deadsuperhero@social.wedistribute.org]

@hugh@ausglam.space A few do, Pleroma historically supported it. Not sure if they still do.

Part of the problem is that it's kind of unwieldy to work with. C2S apparently requires developers to handle all logic on the client side, rather than the server. I've also heard that there's vagueness in the spec on how to do certain things.

The Mastodon API ended up being a lot easier to work with, and overtook the client ecosystem. It actually ended up becoming so popular that most Fediverse clients and platforms have adopted it. It's also one of the factors as to why so many Fediverse platforms are full-stack servers, rather than clients.

I personally still think that C2S has potential, it just requires capable hands to implement.

[Guest]

@rwg @hugh Pragmatically speaking, that's true because people needed to build/show something. But there are gaps in the specs such that broad interop is technically not possible as it stands ( https://w3c.social/@csarven/114178482096355457 ). I'm not saying this to dismiss any work (especially one I was involved in since the days of Laconica/StatusNet). I'm coming from the perspective of how different classes of products can interoperate, regardless of the umbrella or spec "camp" they're part of on the web platform.

[strypey@mastodon.nzoss.nz]

@smallcircles
> what is needed client-side can be found in the AndStatus project ... there were among others no server implementations to test against

Seems like Pleroma had it working before mid-2020;

Pleroma security release: 2.0.4

(pleroma.social)

The Epicyon server has support for AP C2S too, so that could also be used to test apps trying to implement it;

Epicyon ActivityPub server

ActivityPub server written in Python, HTML and CSS, and suitable for self-hosting on single board computers

(libreserver.org)

Was any of this mentioned in the SH thread?

#ActivityPub #APC2S

@skyfaller @hugh
@bob

[naturzukunft@mastodon.social]

@strypey @smallcircles @skyfaller @hugh @bob https://rdf-pub.org is providing c2s. I started Testung with #andstatus but there where open questions regarding oauth if i remember right.

[Guest]

@strypey @skyfaller @hugh @bob

I did not mention a #SocialHub thread. There are multiple discussions where various aspects were discussed, that might still be useful. The search facility is best way to find them.

As for AndStatus the github issue lists their step-by-step progress in investigating what was needed, and what the challenges were. One of them was unavailibility of appropriate server back-ends to test against, mentioned *at the time* as challenge.

Would ️ more #ActivityPub C2S dev.

[hugh@ausglam.space]

@smallcircles @strypey @skyfaller @bob My original question came from the POV of maintaining a, uh, server/client project and wanting to understand why projects aren’t providing server-side interfaces for clients to talk to using the C2S standard. It’s unsurprising there aren’t client projects if there’s nothing to talk to.

But the widely varying perspectives I’ve received are interesting. I was thinking more about pushing data to the server, many of the perceived problems seem to be more concerned with receiving data from the server.

[Guest]

@hugh @strypey @skyfaller @bob

There's renewed interest in C2S and it makes sense wrt current tech trends (local-first, p2p). Can be very useful if you kept a log of your adventures and observations to stimulate others. Would be great to have fresh discussions on SocialHub (where various categories are also federated via the Discourse AP plugin).

[strypey@mastodon.nzoss.nz]

@smallcircles
> I did not mention a #SocialHub thread

True. My mistake : )

> Would ️ more #ActivityPub C2S dev

Am I right in thinking SocialCG have been looking at improving standardisation on that front?

@skyfaller @hugh @bob

[Guest]

@strypey @skyfaller @hugh @bob

> SocialCG

Certainly. And SocialHub with the FEP process. And countless other parties where people give their utmost to improve things. Very valiant efforts.

However there are 2 realities on fedi. One the near stalled (for 6 years!) open standards evolution. And the other where people implement new stuff that introduces protocol decay and tech debt. This increases 'whack-a-mole driven development' that's counter to and detrimental for broad interoperability.

[strypey@mastodon.nzoss.nz]

@naturzukunft
> rdf-pub.org is providing c2s

Awesome, so that's at least 3 server packages to test clients against. Pleroma, Epicyon, and rdf-pub.org.

#ActivityPub #C2S

@smallcircles @skyfaller @hugh @bob

[Guest]

@skyfaller @hugh relying on the client IS the point. It gives people sovereignty over their Fedi presence, and leaves the processing and other server things for the server.

[Guest]

@strypey@mastodon.nzoss.nz @naturzukunft @smallcircles @skyfaller @hugh @bob There are other servers that implement C2S support (ActivityPods, Vocata, onepage.pub, ...). Lack of servers implementing C2S is not the problem. See the many other issues described in this thread for examples of why one can't built an *interoperable* AP C2S client with features a typical user would expect.

[julian@community.nodebb.org]

@smallcircles@social.coop said in As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.:
> Would be great to have fresh discussions on SocialHub (where various categories are also federated via the Discourse AP plugin).

Why? This discussion is already on fedi, so posting it to SocialHub to get it on fedi is just a roundabout way to do the same thing...

[julian@community.nodebb.org]

@strypey@mastodon.nzoss.nz fwiw I'm thinking that C2S might be applicable in an S2S-like setting where a user "logs in" to instance B using instance A's credentials, and B can do limited actions as the user on A. Essentially A would act as the server, B is the "client".

[evan@cosocial.ca]

@hugh Mastodon already had an API when they adopted the ActivityPub protocol, and they did not want to use the ActivityPub API.

I think they made the mistake of thinking that a standard API had to replace their app-specific API, rather than being complimentary.

This is too bad; ActivityPub was designed to make clients innovative and interesting, and let servers concentrate on performance and reliability.

I think as we get more ActivityPub API clients, servers will start supporting the API.

[evan@cosocial.ca]

@hugh I should also say that my book for O'Reilly Media has really good coverage of the ActivityPub API.

ActivityPub book

In September 2023, I started work on a book about ActivityPub for O'Reilly Media. As of September 2024, the book is now available! Ebook The book is available from several different ebook vendors in different formats. O'Reilly Learning Platform Amazon Apple Books ebooks.com Kobo Print The book is not yet available in print format. O'Reilly…

Evan Prodromou's Blog (evanp.me)

[Guest]

@hugh@ausglam.space it's because clients can't make any assumptions about ActivityPub data using the C2S model. They have to perform full client side parsing and linking, then figure out some way to display this graph structure of data they've been given. The fact of the matter is that ActivityPubs design is overly broad, and no client could account for this. So, instances implement an API offering a simple, watered down format, plus the benefit of having stability even if the software moves to another federation protocol down the line.

There's also the matter that almost all ActivityPub implementations do not store posts in their database as JSON-LD, instead they unmarshal the data from it and store it in a concise format. Reconstructing it for the purposes of C2S would be inefficient and clunky.

[Guest]

@julian imho..

Pros and cons of decentralization + current state of fedi as a microblogging dominant thing.

We're on a fragmentiverse,where community waters down, what you send today is lost in history tomorrow. There is no search, no archive.

We are on a good path but the kind of organization we need to mature social web open standards and enabling technologies is not well supported on fedi.

Barrier to sign up to a single forum removed, easier access, but dispersal of the community efforts.