Post
Developer perspective on tradeoffs… #ATProto architecture is more centralized. #ActivityPub has JSON-LD. ⚖️ So much pain and confusion, so little benefit and the Fedi Father refuses to consider JSON-LD alternatives because replacing the “feature” that almost no one actually uses with something useful will apparently break the Fediverse.
“This is why we can’t have nice things.” 😬#fedidevs
@eyeinthesky indeed.
There's a parallel thread on the merits of linked data, that I just gave a couple follow-ups to..
I think a problem is more that instead of "ActivityPub has JSON-LD" you might also say that AP delegates to.. or even 'handwaves' to linked data.
#ActivityPub is linked data --> ✅ Extensibility mechanism DONE"
Which is either..
- By far not the case, if you consider the promise and power of ActivityPub
- May perhaps be true, if you have a very particular notion on what the fediverse is and isn't.
That last bit remained unspoken, so what AP vs. fediverse is, is really in the eye of the beholder. There exists no shared (technology) vision. https://discuss.coding.social/t/major-challenges-for-the-fediverse/67
With the extensibility mechanism unclear, there is no clear separation either to what is protocol and what is solution space, and there's continuous confusion around this.
I replied to @evan yesterday, as his remark would entail that all post-facto interoperability introduced on-the-fly by app impls would have to be honored now in the standards. What standards process does that give?
@smallcircles It's even crazier than that. I saw the thread a few days ago where @cwebber apologized for JSON-LD in AP and @evan defended it (but for backwards-compat, not because AP is linked data). The "extensibility" claim is technical gaslighting since that's only true if you use JSON-LD processing of AP data (practically no one does and there's no requirement to do it). 🤪 Even then it's a weak form of protocol extensibility.
@eyeinthesky @smallcircles @evan To be clear, I think json-ld has a lot of great ideas in it, and it's the extensibility and linked data compatibility (which was a strong group requirement) story we had at the time.
"JSON-LD is bad" doesn't really capture my views. "JSON-LD turned out to be too complicated for the majority of the ecosystem to work with, particularly when we gave the view that you could ignore it, except it creates a rift of interoperability between those who ignore it and those who don't and puts a burden on the latter who are doing their best to behave well" does match my views.
There are paths out of the situation, but I'm not confident in the discourse around them right now, and hesitant about how much I want to engage with it.
> There are paths out of the situation, but I'm not confident in the discourse around them right now, and hesitant about how much I want to engage with it.
Yes. I posted something on the same subject today.
@cwebber @eyeinthesky @smallcircles @evan Apart from the fact that I would prefer turtle, I am very happy that AP ‘prescribes’ json-ld. This opens the door to many of my ideas. It makes possible what would be very complicated without #RDF. It's about time that the AP developers got to grips with it! https://rdf-pub.org/#rdf
