If you think outside the centralized server, I could fairly quickly implement my fragment of a distributed twitter. It's a matter of declaring a few objects/types, and writing code to do CRUD for my locally hosted parts, replicate those to some publicly accessible file host/web page, and them write an engine to scan all the other sites where the people I follow publish their data.
Two things that can't be replicated:
1> blocking of users. Once data is public, you don't get it back.
2> anonymous comments or replies. This would require scanning all replies, even of people you don't follow. It's possible this could be a service from a 3rd party aggregator.
I agree that data has to be converted, but I don’t agree that it has to be as manual as it is today. Consider this: In addition to your API, a second JSON file gets generated that describes the schema of the first. On the consuming developer’s end, their language & IDE uses that schema to let you call APIs or RPCs exactly like they were local functions.
If you have function calls without type information, anything can happen, a function call could result in your neighbor's pool being drained, and your bank balance being sent to Belize.
In Pascal, you have to have a type before you can declare a variable. This little inconvenience saves you from an entire class of errors.
If I'm going to import a random file from the internet, I have to be sure of the type of data in it before I'm going to touch it with a 10 foot pole (or barge pole in Britain).
I had no idea people got so foolish.
Back to your idea, of course there should be type information, either as a separate file, or at the head of the file.
In Pascal, I'd have the import routine check it against the RTTI (run time type information) of the local native structure as part of the import, and throw errors if there were problems. On export, the RTTI could create the type header file/section of JSON.
That's why Emacs is still great: users can do whatever they want with it, and they do.
To a lower degree, we can sort of do that with workflow engines on the cloud (ex: Azure Logic Apps), or locally (ex: iOS Shortcuts).
As a user, I like being able to do that, but I do not like having to maintain my partially working thing, nor do I want to spend time ensuring it works as I expect (aka doing QA) outside of what I use it for today.
I wouldn't see potential maintenance or QA work as a deterrent to mainstream adoption. Users would underestimate it just like developers today do.
But even then, it did not get picked up. Sure, you could do a lot with MS Excel, but non-Ms software often had spotty or missing ActiveX support.