I can see a lot of use cases for a json payload (in my head that’s in content). What are the downsides?
Discussion
Bad clients parsing it wrong
This feels like a client problem, not a nostr problem, no?
Yes, entirely. I beleive json in content is good. I have a git repo in my metadata.
But I know from experience that at least 1 popular client, which I'm not going to name,
tries to parse everything that has a dot in it as a link, and anything with a # as a tag.
There should at least be an option to turn that off. But yeah, client problem, not mine.
Yeah I know which one you mean and that’s annoying as hell.
You’re totally right that json contents would (at least at first) net increase client issues. I think that’s not a compelling case for the prohibition of json contents though. Especially if there were a dedicated kind that was associated only with json contents.
no one is talking about prohibition
you can do the same thing, sticking json in an event, without putting it in the content and allowing clients to almost-always be able to present something that is human readable; just put it in a tag, like nip-57 does
I always understood kind 1 as plaintext.
But there is no such thing as plaintext.
one in the same
How so?
downsides:
* interoperability (what's being discussed on this thread)
* you can't query relays for json in the content
* it's probably unnecessary when you don't try to shoehorn data structures into nostr events without thinking about how nostr works to model your data
when I first started developing nostr stuff I had the inclination of putting everything structured into a json, the more I think about it, the more I think this is generally unnecessary (not saying that it would never be the case)
ultimately you can just do the same thing but put the json payload in a tag, like zaps do, and keep client interoperability with unknown-kinds working
that third one is probably the strongest argument, and definitely i see your point better now