search

nostr-protocol / nips

Nostr Implementation Possibilities
2.4k stars 583 forks source link

NIP-34: clarify issue title #1505

Closed DanConwayDev closed 2 months ago

DanConwayDev commented 2 months ago

added as dluvian implemented the title as a subject tag in voyage which caused the issue title not to display in may clients such as: amethyst, Nostter, nostrudel, coracle and gitworkshop.

nostr:nevent1qvzqqqqx25pzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy88wumn8ghj7mn0wvhxcmmv9uqzqqta74rkqgzt4akdw3acrparwnq46u2dusg4fzuu2d7ppyhgcmu6kz2ahd

vitorpamplona commented 2 months ago

I would prefer that clients change to show the subject as the title. The NIP just needs to add it to let people know this is the case.

DanConwayDev commented 2 months ago

@dluvian also thinks that. I don't mind changing but right now it displays really well on a lot of clients. My assumption is that a lot of clients show the content of events with an unknown event kinds.

My concern is every client will have opt-in to displaying the title and otherwise just show the body which will omit context.

fiatjaf commented 2 months ago

A lot of clients show the subject tag too.

But if your main concern is just displaying on all clients then this should be a kind 1 if taken to the extreme.

dluvian commented 2 months ago

The NIP just needs to add it to let people know this is the case.

I have a PR for this: https://github.com/nostr-protocol/nips/pull/1446

DanConwayDev commented 2 months ago

A lot of clients show the subject tag too.

Can you give an example of a client that shows it in the preview of this referenced nostr git issue? nostr:nevent1qvzqqqqqqypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy88wumn8ghj7mn0wvhxcmmv9uqzpyfr4pztjtjrwrfg89k76xtmgpcqerz3xr8u2fw7jn9mzhvvvsgeyylvdp

fiatjaf commented 2 months ago

As far as I know Amethyst and Gossip display the subject tag of normal notes at least.

But this is more a question of principle. Can we hack all the datatypes possible in the world as strings inside the content field of kind:1s? Yes, we can. But should we?

vitorpamplona commented 2 months ago

I am not sure we show subject on the issue event, but it's just because it was never described as the title in the NIP. Any client can easily add this. They just need to know :)

There is no subject tag in this event: nostr:nevent1qvzqqqqqqypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy88wumn8ghj7mn0wvhxcmmv9uqzpyfr4pztjtjrwrfg89k76xtmgpcqerz3xr8u2fw7jn9mzhvvvsgeyylvdp

DanConwayDev commented 2 months ago

There is no subject tag in this event:

The git issue referenced in the event is nevent... Most clients will stumble across git issues in non-specialist clients via references in other events so I was trying to give an example of that. Here is that example in njump.

I'd like it if clients handled unsupported kinds differently, but its not the world we live in. Why make it harder for 'other stuff' to be displayed properly?

I think most clients display a preview of content, whereas it would be better to display the alt tag, fallback to the subject and then fall back to the content.

vitorpamplona commented 2 months ago

We shouldn't design anything for unsupporting clients.

Clients that just display the content of the event they don't support are just losing context in every NIP. That's not the way to do it.

We would have to put everything in .content if we start designing for that.

pablof7z commented 2 months ago

Agreed with what was said.

NACK.

DanConwayDev commented 2 months ago

A rough consensus has formed. I've updated gitworkshop.dev to use subject. Can we merge #1446 which adds this to the NIP? Thanks everyone for your input.