The format really isn't the interesting question. The interesting question is how do we get clients to behave predictably with each other. If you start breaking the schemas that everyone on the network is using, then yes your posts should fail to render and probably be ignored.

Without defining these schemas to allow for flexible mixed media documents, you're always going to have chaotic implementations floating around.

As long as your body is a plain text, you can present it in a very wide variety of ways and styles. Once you allow formatting and inline images, you start moving towards HTML documents, and lose consumer's control over content.

How is that different from XML if your body is defined as a text field?

what is the argument here? why didn't you know you answered your own question

"body":"Why didn't you use <img src="xml_has_its_uses.png"> XML!?"

You're assuming HTML string, which might not always be correct. What do you do with Markdown?

You need to have a standard way to represent things like this, because otherwise it won't gain traction solely due to the immense complexity of implementing viewers.

Edit: On top of this, HTML might not necessarily be the best choice. In that case it'd just be browser wrappers galore.

everyone is already used to making their frontend, backend and database parse and store external things in key value pairs

this schema pre-detecting ship has sailed a long time ago

  {"body":{
    "childNodes": [
      {"span":{"textContent":"Why didn't you use "}},
      {"img":{"src":"xml_has_its_uses.png"}},
      {"span":{"textContent":" XML!?"}}
    ]
  }}

if you wanted to "include images or something of that sort" you would add an "images" key or a "something of that sort" key

in your particular example, body can clearly take image links image data as string and the parser can deal with it.

in my projects we typically would have a nosql database which out the box allows it to be indifferent about objects in a collection/table that include or exclude certain keys

>and the parser can deal with it.

That's not ideal. You need a defined schema so that the majority of parsers can reliably parse the majority of objects.

>in my projects we typically would have a nosql database Parser implementations shouldn't be assumed to use the same or similar tech stack that you do.