I worked at a company at one point that had this happen with a database.
They really wanted at some point to be independent of the specific database. They wanted to be able to swap to different databases in the future. I was told that "we write pretty standard SQL so we can swap in the future" and all of the driver-specific elements were hidden behind a common tool (not dbcp, their own custom one, because of course).
They resisted strongly using db-specific improvements or optimizations
Everyone who knows SQL at any level of depth knows what happened next.
So what you ended up with was a situation where they were deeply tied to PSQL and it would have taken a monumental effort to move to a different provider… or in some cases even a different version of PSQL.
Because absolutely no one knows what the PSQL specific functions are or thinks about these things when writing SQL, and recognition of it was spotty (some standard SQL features were thought to be PSQL, etc).
Compare and contrast with another company that I was at that had to switch between MySQL and PSQL at one point and used HSQLDB for testing.
But literally everything database related was built on top of Hibernate.
Hibernate completely abstracted this question out. There were a few things that needed to be adjusted around types and such, but the work was essentially trivial to move between MySQL and PSQL (and the swapping with HSQLDB was also essentially trivial to set up).
I think that #ActivityPub in many ways fell into this same quagmire with both JSON-LD and with HTTP. They wanted to be generic to the underlying systems, but you can't actually get away from them.
As Nietzsche famously talked about: You can't just kill God and then pretend that all of the systems and norms and morals you've built on top of that belief still hold true.
So in a real way I would argue that it is bound to both and you can't get away from it, but it takes advantage of neither
As much as I dislike #JsonLD for this use case (and oh can I tell you about why I dislike it for this use case), I actually think in many ways #ActivityPub would be better if it went all-in with it.
Because right now I can't use any of the features of JSON-LD that make it actually powerful, but I've inherited a lot of the problems with the worldview.
HTTP is similar (except I don't hate it for this use case): by not committing we end up in a half-state. Neither fish, flesh, nor fowl.
We could create more distance w/ JSON-LD, my theoretically-RSN FEP talks about this, and @smallcircles has talked about the difference between thinking of it as "linked data first" versus other models and approaches. Same with HTTP: make there be an "HTTP extension" to #ActivityPub.
Another is to go all-in and take advantage of the underlying features and frameworks in either/both (e.g., OAuth).
But I don't think as we evolve the current situation is tenable.
@hrefna the PLSQL example was hilarious to me, as it brought back memories to what I experienced after our company got taken over by another that had created the PLSQL-from-hell spaghetti monster.
Wrt approach to choose imho key is what DX is offered to the person implementing AP.
"AP is LD, which is simply almost-json, see this spec, this spec, this spec, and this one, and enter the World of LD". That road doesn't make clear the WHY. What does all that effort bring?
I think much of the hate/aversion with devs stems from not seeing the benefits, perceiving overkill.
As long as "JSON-only is okay" there is overkill. Creating good @context becomes afterthought.
Going "always-LD" and then good guidance + minimalistic starter may be an approach. The tools/libs aren't mature for many languages. And the installed base is left behind on this vNext AP.
My gut feeling is that LD-aware use cases first have to prove their merit. "Hey, only LD can do this!"
The LD trajectory has to trigger excitement on all the things it makes possible. All that is intangible now. "if only we had semantic data, so much becomes possible". Like what?
There are applications of LD that are large-scale and successful. SEO, Google knowledge graph, maybe Wikidata. But it is unclear how that relates to exchanging LD-formatted msgs on the Fediverse wire.
Most other LD applications I've seen exist in academic fields, are powerful and flexible, but have ugliest UX.
Another field where LD is more popular is in governmental environments, and maybe larger enterprises. B2B applications in environments where there are many different interfaces to remote systems of all kinds in complex organization structures, and hence it is worth going the extra mile to have the data be malleable as LD.
A future Social Web would have a similar kind of setup. We want to get to a state where tons of independent parties can bring one piece of the 'social experience' puzzle. Add one service or component to a growing social fabric.
Getting there requires thinking differently on what it means to "become part of the Fediverse", as it goes further than adding some narrow pipe from your app to a similar app.
@jenniferplusplus It could standardize on OAuth (or whatever), for starters, and describe sessions. There's also things like being able to create RPC-like abstractions (ATProto's approach: https://atproto.com/specs/xrpc) more easily, define common error codes and formats more precisely, or use, e.g., PATCH and PUT verbs.
The biggest in my mind though could be more robust content negotiation as standard and the ability to more easily define non-LD profiles for what the data ultimately looks like.
@jenniferplusplus But more it is about what we aren't talking about in the spec
There's nothing on CORS, or how to handle large payloads (outside of the pagination, but no 413), and no compromises around how to handle identifiers (because they didn't want to say "everyone needs to have a unique username like foo.example/~hrefna" but they also didn't want to standardize on webfinger or an equivalent)
Taking advantage of it means we can say "we can't use ~hrefna naming, what else is there?"
@jenniferplusplus None of that is absolutely guaranteed, of course, but our current state is the result of the kind of compromise you get when everyone acknowledges "doing it that way is terrible and there are solutions in the field to work around it, but we can't standardize because we want to stay abstracted."
@jenniferplusplus Also completely selfishly and more pie-in-the-skie… if it were a "HTTP first" system I would have room to say "this needs to support OpenAPI" and use the fact that it is HTTP as leverage to encourage support for OpenAPI or somesuch >_>
Basically it isn't HTTP itself so much as that it allows one to leverage that fact for other conversations.
Well, silver lining, since activity pub doesn't specify content negotiation, that does kind of leave us free to use it ourselves to enable a parallel (or v2? 🤔) protocol.
Add comment