ActivityPub: A Linked Data spec or JSON spec with Linked Data profile?

[aschrijver]

@bumblefudge

AP is already what Tess O’Conner from google calls a polyglot spec

This is a great article, which I overlooked the 1st time you passed it on chat.

@bumblefudge

That’s why I am lobbying for having test suites and documentation ASAP

for both test suites and docs. Whereby the docs can only go as far as explaining the fundamentals (“core spec”, must-haves) and best-practice guidance for implementing AP extensions.

@bumblefudge

punting as far into the future as possible holy wars about the lowest layer of the specs as these can only harm the fragile interop we have today.

Here I’m less sure. We already did that and it leads to increasing tech debt and/or extra effort to achieve interop (the double cost of a polyglot spec that the article mentions). Now, while good test suites and docs help make that more bearable, this is asking a JSON-only developer to define a @context they don’t care about.

@bumblefudge

going in a drastically different direction is not a minor upgrade […] I don’t want to lose the JSON-only developers, and I don’t want to lose the Solid/RDF/JSON-LD folks either.

I agree with this. I’m specifically pondering whether there’s a non-drastic way to go from “JSON-LD first, JSON-only second” to “JSON-only first, JSON-LD second”.

First of all having an alternative means to define an extension (e.g. with JSON-Schema and Compliance Profiles referencing docs) is an addition, not breaking backwards compat.

Second consider how a JSON-LD-first developer in current environment gets to integrate stuff from a JSON-only developer:

• @context that is an afterthought, full of errors or design flaws.
• Properties and types not defined that the spec says to ignore.

And the other way round:

• “Please JSON-only developer master enough of Linked Data to understand what I pass along”

In other words the double cost. The article you linked describes a way to solve this at the end.

@bumblefudge

Personally, I will probably pack my bags and go do community work in another community if the question of tearing out 1/3 of the spec

Luckily this is not the subject in this thread I aimed to address

Let’s assume availability of the test suites and docs and consider the 3-stage / concentric circles Standards Process with the W3C at its heart.

Standard Process stage	Present day	Fediverse Futures
3rd-stage, outer circle: Decentralized dev ecosystem	Copy what others do. Ad-hoc extension in codebases, protocol decay and tech debt. Extensions mostly not usable by LD devs.	Slight improvements with best-practices to follow and extensions tested against these. Extension mechism works for all. Extensions may still not be directly usable by LD devs.
2nd-stage: SocialHub / FEP process	Extension spec is iterated on with more community attention and potential for broader consensus and future adoption.	Extension spec quality is significantly improved in more authoritative (yet still grassroots) process. Compliant extension MUST be Linked Data compatible. LD devs are well served.
1st-stage, inner circle: W3C formalization	W3C is rebooting activity in CG/WG charters. Provides informal guidelines (e.g. wiki’s), not yet sufficiently fleshed out to resolve the LD/non-LD conundrum. No guaranteed LD compliance.	W3C provides robust guidance. Proven, widely used FEP’s from 2nd-stage and specs from well-organized 3rd-stage devhubs are further formalized in W3C artifacts. All work is LD compliant.

@stevebate

discuss the best path going forward.

Yess, exactly. We are currently in a special stage of Fediverse AS/AP evolution, where for the first time in years we have sufficient community interest to bring improvements on all fronts. We should use that time to allow us to be open and brainstorm about solutions for challenges that have plagued us so long. And then decide the who/where/how/what to put the solution into place.