Well, a zap event, for example, has either empty content or a random comment as the content. That will make no sense for a client that doesn't understand zaps.
Do you think going forward new event definitions should reserve the content field for a fallback self-descriptive string?
yeah, 9735 are even more special because the pubkey of the event is not really the pubkey of who originated the action, but perhaps it wouldn't be a terrible idea if zap events included a content of what it is; most clients don't permit responding to a zap event but I think that should definitely be a thing
regardless, I think `content` should be largely reserved for human-readable data
I think json in `content` is an anti-pattern (I did json content in ananostr as one of my first nostr projects and that totally changed my mind)
I can see a lot of use cases for a json payload (in my head that’s in content). What are the downsides?
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
Being able to pass structured data without having to define a new NIP is good
What's not good is that some clients try to forcibly parse any content expecting a social media post with hashtags and links...
that doesn't matter: whether you pass it as json, tags, or whatever, if you want a kind/format supported by others, you should standardize it via a NIP, it's irrespective of the format you choose
Only a select few people get to define new NIP standards lol... If I want my data transferrable to EVERYONE, I build it on NIP-01...
huh?
using tags is perfectly compatible with NIP-01, no idea what you're saying
I tend to agree with this.
Maybe we should add this stuff to NIP-01.
I agree, content should be human readable. Metadata belongs in specialized tags
