Nostr Web Client

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?

PABLOF7z 2y ago

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)

Reply to this note

Please Login to reply.

Discussion

Zach 2y ago

I can see a lot of use cases for a json payload (in my head that’s in content). What are the downsides?

CodeWarrior 2y ago

Bad clients parsing it wrong

Zach 2y ago

This feels like a client problem, not a nostr problem, no?

CodeWarrior 2y ago

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.

Zach 2y ago

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.

PABLOF7z 2y ago

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

Josua Schmid 2y ago

I always understood kind 1 as plaintext.

But there is no such thing as plaintext.

PABLOF7z 2y ago

one in the same

Zach 2y ago

How so?

PABLOF7z 2y ago

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

Zach 2y ago

that third one is probably the strongest argument, and definitely i see your point better now

CodeWarrior 2y ago

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...

PABLOF7z 2y ago

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

CodeWarrior 2y ago

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...

PABLOF7z 2y ago

huh?

using tags is perfectly compatible with NIP-01, no idea what you're saying

CodeWarrior 2y ago

hmm you're right, I guess I just didn't consider that because none of the clients I used so far allowed custom editing of tags

fiatjaf 2y ago

If you're doing custom data and custom event formats you probably need a custom client too.

fiatjaf 2y ago

I tend to agree with this.

Maybe we should add this stuff to NIP-01.

fiatjaf 2y ago

What does everyone think about this?

nostr:nevent1qqsqp7kjtqqkezgdauggwgtqpel2ju2u665rrv29gruy0rjqjtjr0rqpyfmhxue69uhkummnw3ez6an9wf5kv6t9vsh8wetvd3hhyer9wghxuet548enyk

Blake 2y ago

Maybe there are two parts. Previously I suggested another approach too - see below.

1. We should be able to reasonably have a kind to kind label mapping that can be used to at least give context in apps. That’s a step forward.

2. If that kind can somehow give a fallback content or similar, great. Maybe the equivalent to the noscript HTML tag or img alt attribute. Dupe data, but that’s life. A tag is better suited long term than the content.

Additionally, we could somehow have registrable Nostr event kind url handlers - so you can tap the placeholder to load it in a different application. I don’t know how this scales perfectly, as url handlers may not allow kind ranges.. but worth experimenting. Apps are likely linked to target kinds over ranges anyway.

PABLOF7z 2y ago

nostr:note109vmhelg2r8z09jat5krn8ge26mtn5686yjsc99k8ups0lf9dvfq0p5wjt

jb55 2y ago

No harm having a fallback comment. The user comment should be gathered from the zap request anyways so the zap comment could have anything in it. I don’t have much hope in everyone updating their zappers, but wouldn’t hurt.

gsovereignty 2y ago

I REALLY like the idea of keeping content human readable. I agree that JSON in content is an anti-pattern.

Problem: I need arbitrary JSON in events.

Solution?

I've gone through the "put it in tags" phase and nobody liked it.

fiatjaf 2y ago

Nobody who? I like it. I dislike JSON in content myself too. It is ugly and awful.

gsovereignty 2y ago

I posted in the tg group like a year ago that it should all be in tags not content, 5 chars = namespace of 1M tag types. But everyone said bad idea just use new event kinds and put it in the content.

I also said we need names anchored in Bitcoin instead of DNS but no one liked that either.

Kids these days...

Anyway, I'm not up to date on all the latest gossip, what's the current thing now? Put it in tags? Or something else?

nothenry 2y ago

I agree, content should be human readable. Metadata belongs in specialized tags