Right now:
- Either this thread has gone massively off-topic from listing desired changes.
- Or it listed the single one biggest pain point that exists in AS/AP today.
IMHO it is the latter. The specs say “We are linked data JSON-LD notation, but you may use plain JSON”, and subsequently the developers in the Fediverse ecosystem decided they preferred plain JSON. Linked data solutions are the exception, not the rule.
Linked data as a suite of open standards in general is not a well-trodden path. It has weak adoption and tool support, and specs themselves are still evolving. After many years linked data just isn’t there yet, hasn’t fulfilled its promises. And pushing its complexities through people’s throats while they do not see its merits only helps turn them away.
AS/AP must make a choice. The either/or pick’n choose of JSON-LD vs JSON makes no sense.
If you say something is linked data, then there’s N open standards it should comply to. If people can consider plain JSON they’ll not care for any of those. You get both crappy linked data extensions as well as plain JSON extensions that way.
What Linked Data is best suited for is as a host of standards that allows any data to be marked up as information so that tools in a best-effort manner can reason about and infer its semantics. As @trwnh says this allows vast open world knowledge networks to be created. Undoubtedly where crawlers, reasoners, inference and semantic query engines plus AI make the most of this semantically hyperlinked data.
IMHO this is not what is needed for the AS/AP communication protocol of the Fediverse.
It may be part of what is needed, as message exchange between actors using the email-like addressing mechanism also forms graphs in the content that aggregates at any endpoint via inboxes/outboxes.
But for modeling robust heterogenous interoperable services on the Fediverse the message exchange itself is most important. In other words AS/AP is first and foremost a message-based communication protocol. (And it may even be that it spans up an event-driven architecture, where each activity sent indicates something that already happened).
Interoperability i.e. interfacing to a remote endpoint requires:
- Data model and message formats that are supported.
- Information about the business logic related to 1).
- Information about message exchanges that are supported.
It is not enough to just define extensibility for the msg format, which is the extent to which JSON-LD helps us currently. If we’d had JSON Schema and some namespacing mechanism it’d be just as good to satisfy point 1) or another option may see use of Linked Data Modeling Language as I suggested before.
But point 2) and 3) aren’t covered by any standard. In order to do these well, eventually there’s good quality documentation that should be available and discoverable. And its quality and value depends on its level of interoperability (custom/app-specific vs. standardized), which in turn depends on collaboration and finding agreements within domain-specific ecosystems that develop particular servives.
There’s OpenAPI and AsyncAPI. For the exensibility mechanism of the AS/AP-based Fediverse we might have federated specifications, whereby each endpoint / actor offers the means to discover its interoperable specification.