Robert W. Gehl @rwg@aoir.social
Public

@hugh In addition to the concerns expressed here, I argue in my book that Mastodon's status as the single largest ActivityPub implementer back in 2017 is a factor -- after all, Mastodon had an API at that point. People making clients chose to make them compatible with Mastodon's API instead of redoing everything for the then-new C2S spec.

Sarven Capadisli @csarven@w3c.social
Public

@rwgRobert W. Gehl @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 ( w3c.social/@csarven/1141784820 ). 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.

Sarven Capadisli (@csarven@w3c.social)

@jim@social.openrightsgroup.org They're all generally internally consistent and interoperable. My point re authn/z, was that #ActivityPub for example doesn't define particular mechanisms, which is why an independently developed AP-client and AP-server can't talk to each other. Ditto AP-server w/ another AP-server. That's based on spec, as opposed to specific implementations agreeing on terms prior to communication / out of band. What's out there is mostly a software implementation offering both AP-client and AP-server.

w3c.social · w3c.social

0
0
0

If you have a fediverse account, you can quote this note from your own instance. Search https://w3c.social/users/csarven/statuses/114422121230102350 on your instance and quote it. (Note that quoting is not supported in Mastodon.)