Yes that's what has become clearer to me as more people outline what they think the gap is (surprise: they don't all agree on that). There's a chasm between what the people writing the spec were imagining, and what most projects that use AP are trying to do. While the lack of detail on authorisation is a pretty major problem, it now seems to me that to a fair extent the issue is more a mismatch between the conceptual model of the ActivityPub spec (thick clients doing the work, with servers passing messages between them) and what most fediverse projects are trying to do (tightly-coupled server-client apps that talk to each other).

hugh@ausglam.space
Posts
-
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. -
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.@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.
-
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.@skyfaller Well one person’s “under-defined” is another person’s “flexible and simple”. If people get their heads out of micro-blogging it becomes clearer why a more rigid definition becomes limiting, IMO.
-
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.@skyfaller Thanks. I guess I’m looking for more detail on what is meant by “underdefined” and “relies on the client to do almost everything” because my reading of the spec is that it relies on the server to do almost everything! I assume I’m missing something, but everything I’ve read about it is very vague.
-
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.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.
Any fediverse devs able to explain why? Is there a technical reason/limitation, or is it more about other considerations?
I'm looking for information here rather than speculation, thanks.