So hear me out here: I think on one level everyone here is talking about whether the spec is fundamentally JSON-LD with a JSON-only variant and whether the inverse is possible. The crux of understanding status quo (and the biggest challenge with coming up with a good replacement, i.e. actually writing the JSON-only v2 or even v1.1) is how extension logic works in the “open world” of actual decentralization. I won’t belabor or summarize, but I really think this is the tricky bit. We can disagree about conclusions but it seems a common understanding that this is a philosophical disagreement about how best to experiment at the level of protocol extension without imposing priorities or constraints on that extension OR requiring central authority over tomorrow’s protocol. That’s the trillion-dollar question! Say what you will about blockchains, governance over those protocols once they’ve become enmeshed in chaotic international unregulable capitalism proves it is really really hard to govern a living protocol once real-world value is being transacted over it. If you don’t believe me, you should look at the size of Threads’ budget.
I think both sides here are very smart, and that needs to be said out loud due to a quirk I like to call the “engineer nerdswiping gene” which is an unfortunate side effect of being smart enough to have read this far in this hellthread. there are good and valid ways of iterating the AP spec that are fundamentally “JSON-LD spec with JSON-only implementation guide” (status quo, but as @stevebate points out, harder to finesse and probably require a much more detailed explanation of expanded form JSON-LD as an option for protocol extensions). There are also good and valid ways (probably many more of them!) for iterating the AP spec that flip the “cardinality” and make the spec easier to extend, but harder for JSON-LD implementations to interact with extending JSON-only implementations.
More importantly, this might be a distinction without a difference, because they require a lot of the same gymnastics that steve is pointing out we need either way-- if JSON-only implementations can originate extensions without accomodating JSON-LD in one form or another, we’re just doing the same amount of hack jobs, except on the protocol upgrade side of things (i.e., JSON-LD implementations’ interop is broken until each major version…). Pain upfront or pain later, in many ways-- like so many engineering tradeoffs, the question is who does the hard work when, there’s the same amount of hard work either way.
So the common ground might actually be more useful to explore than the holy war. I will also add that the DID and VC working groups grappled with all the same problems for the last 5 years; the hardline “JSON-only” folks ended up going to IETF and restarting the standardization process in many ways, which fundamentally makes the either/or engineering tradeoffs a matter of zero-sum, wontfix non-interoperability. The resolution of the interop problems will come when either the JSON-only-first or the JSON-LD-first verifiable credential standard becomes betamax and fades into history, it seems. That feels like a governance failure mode, because one side or the other will have wasted a decade in that future. Who said capitalism was efficient!?
Anyways, that’s about all I can say about “the holy war” I’ve referred to in other threads. That’s one layer on which we’re disagreeing which is literally ideological-- how do we think standards should be written, which is the fundamentally saner approach to these very hard problems.
On another totally distinct level, let’s call it developer-experience pragmatism, there is a very real developer burnout issue here. There are like 200 partial implementations of AP that were never finished because no one started out wanting to deal with all this. As strypey mentioned in another thread, this is partly because making “federated software” has all the problems of making software on top of all the problems of making software federate, and it’s unclear why everyone who wants work on one set of problems should also be forced to work on all of the other as well.
Isn’t this why libraries exist? Might part of the problem be the insane ambition of people trying to single-handedly make something the size of a browser or email program, WHILE ALSO making something as complicated as a blockchain consensus mechanism that can negotiate in open-world, living-standard protocol with interlocutors that recognize no authorities in common?!?! When you put it that way, it sounds insane that everyone is expected to bite off ALL THIS.
Splitting “making fediverse software” off from “making smooth interop across moving-target protocols” would be possible if core libraries like fedify handled not just the de/serialization of the JSON-LD wire format but also the S2S mechanics which are… really the only other part where you’d need to know what JSON-LD is.
Forgive me if this sounds insane, but I think that regardless of whether the core spec and/or its “authorities” consider the spec fundamentally JSON-only or JSON-LD, whichever side of the holy war you consider the “extension” and which the core, the functional outcome either way requires the extremely finicky crap to be outsourced to a blackbox library anyways.
I.e. we might be fixated too much on who’s right and what the spec says and not enough on what the spec does, because until the library layer and the software layer are distinct and there are “federation libraries” in a few languages, it’s not going to be easy enough for developers to realistically make good federated software anyways.