R
@kopper @hongminhee @cwebber Oh, I see what you mean. We had that (very heated) discussion in 2004 between the RDF folks and the XML folks. You're using JSON like the XML argumentation back then. And yes, it is possible to re-invent RDF functionality using JSON or XML. This was the point of the 2004 dispute. JSON-LD is only ONE way to solve those possible conflicts. It just happens to be an interoperability specification we call "recommendation".
Sorry for my misunderstanding on namespaces.
@kopper @hongminhee @cwebber and to know other people being really happy with JSON-LD and really needing this functionality, you need to get out of your own application context and into data flows. E.g. Trade transparency. And they may also use activity pub at some point:
https://uncefact.unece.org/spaces/uncefactpublic/pages/246317069/Verifiable+Credentials+for+Trade
Talking of kool-aid, note that I'm only the lawyer. 
@kopper @hongminhee @cwebber but the JSON parser will not recognize naming conflicts. We are talking about data flows beyond the application context. I see you arguing in a social-media distributed twitter context and not a millimeter beyond. That's ok
Inside that context, JSON-LD remains valid JSON and your implementation can ignore the context. But as soon as you want to annotate stuff and NOT hardcode it into your app, this context becomes important.
@cwebber @kopper @hongminhee If we consider data exchange just in one application context (mastodon), then JSON-LD is overhead because data structures are fixed.
But as soon as we go out of that application context, JSON-LD will make a lot of sense. IMHO, the use will grow over time as this allows to add permissions to post on the data level using ODRL e.g. Or to have privacy considerations.
On a very short term, JSON-LD may be an overhead. But it is an investment into the future.
@cwebber @evan @kopper @hongminhee For the purpose of "message" wouldn't it then be easier to just sign an entire file that is transmitted? Or is this stream processing.