@manlycoffee given that protocol extensibility isn't well defined, protocol flavors are created all the time, protocol decay introduced (broad interop becomes ever harder). Imho there's merit in considering #ActivityPub to be JSON-first and have a JSON-LD approach for those who wanna go the extra mile.
An extension for a particular domain requires docs/specs and validation, where JSON-LD isn't best suited. See:
It might be useful to define what different levels of interoperability mean as more diverse implementations with very different motivations and use cases enter the network (that can never fully interoperate and would not need or want it)
There is probably something like the "minimum" interoperability that is required and useful but this is not jumping at you from the specification. Maybe thats why conformance testing is still lacking?
Yes, indeed. While at the level individual apps the use cases are often domain-specific (either conform an application domain or a business domain), you can define / specify / standardize on more granular building blocks within those that could be reused in many different contexts / domains.
I made a sketch of that idea in relation to defining Compliance Profiles on #ActivityPub endpoints. See:
In addition we often discussed that there's likely - and that's what you refer to as well - something of an ActivityPub Core, which is this minimum stuff to implement in any fedi app or service.
@smallcircles@manlycoffee what I would ideally like to have is a layered #activitypub approach (its core, mantle, crust if we use a geological analogy) where each additional layer provides enhanced functionality and eventually things split into continental plates that do their own specialties.
At the very core it could be something very simple, e.g., servers ping each other, exchange actor lists, basically just establish what the network is. Next level support #rss type notifications etc.
Add comment