The: Daniel⚡️ @The: Daniel⚡️ - 8mo
It’s weird that nostr clients can’t even seem to agree on how to display the names of users. Some have a field for “name” and nothing else. Others have “display name” and “username” or “handle”. Depending on which client you see my profile on, my name looks different. Can’t we even get that one basic thing settled?
SamSamskies @SamSamskies - 8mo
Nope. That’s why we have different clients. 😂
But we’re the same users! 🤣
Shaun Dunn @Shaun Dunn - 8mo
But, they're different clients.... 😜🙃
Vitor Pamplona @Vitor Pamplona - 8mo
Mostly because those fields names were never part of any NIP. They are all ad-hoc.
What would it take to get to a basic consensus on this?
It's just about picking the names and writing the NIP. Maybe nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 can use his dictator powers to choose which fields should be used for names and what they should mean semantically. I would follow whatever the NIP guidance says. This is the typical case of too many cooks in the kitchen. We just need to pick which fields are the right ones and update our UIs.
Fabian @Fabian - 8mo
NIP-01 defines “name”, it would be nice if all clients just used that and nothing more. I think the confusion and all other fields comes from it describing to put a username in that field, instead of just name so people invented other fields to put names.
There are way too many name fields, agreed. I would be happy just seeing “name” and then let NIP-05s be an additional way to reference a user. We already have npub, it’s too complicated to add more than that. Who goes first to start removing some of them?
Seems like low-hanging fruit to get this done while we’re kind of in a new user enrollment lull. nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub1n0sturny6w9zn2wwexju3m6asu7zh7jnv2jt2kx6tlmfhs7thq0qnflahe nostr:npub16c0nh3dnadzqpm76uctf5hqhe2lny344zsmpm6feee9p5rdxaa9q586nvr nostr:npub1atc6zwsr9nnyn0rq72g2qqznr3x4yhm20g50wsexjukygwrg9atqh0lssy
I think we need Jira on nostr. 😆
Like they say, it’s like herding cats, except in this case, it’s probably more like herding ostriches, and I’ve never tried to do that before.
3bf0c - 8mo
"name" is on NIP-01. Why can't we just use that?
I know Damus has been using "display_name" since a long time ago, but I have never seen "handle" or "username". This is beyond absurd.
Mostly because many clients break when there is a space in the field they consider to be a username. Like when you @ somebody with a space, it might break them. That's the reason I started filling in the displayName part.
Why didn't you use "display_name" like Damus then? Or is Damus doing "displayName"?
We save the same value on both displayName and display_name. We also save username and name the same "username" value. But we display only one name, the first in this sequence: displayName, display_name, username, name.
This is Primal and Amethyst. https://image.nostr.build/257e30ea39b23e9d441808b303de5d3ec7c4d661778046db474d3ae613853e69.jpg
This is so bad.
Vic @Vic - 8mo
How so? client choice
Why not also "handle", "nickname", "display", "DisplayName", "nick_name", "user_name", "user", "Name"?
Just because it's written "handle" in the UI doesn't mean that is what they save in the event content.
good ideas. make the profiles more robust. id also add alias, gamerTag, lolliTag, instagramHandle, MySpaceName, nintendoFriendCode still up to clients how and what they render. still up to relays on what they will store. thanks for choosing a data structure that is open ended to accomodate this.
It’s really confusing to users. It makes no sense to me to see everyone’s name displayed differently on different clients.
Equally makes no sense to me that I cant lock down or tag a name for someone elses account from my perspective so it remains consistent
You must be trolling so I will start ignoring you.
It looks like the same username field, right nostr:npub16c0nh3dnadzqpm76uctf5hqhe2lny344zsmpm6feee9p5rdxaa9q586nvr?
jack @jack - 8mo
💯
Intuitive Guy☯️⚡ @Intuitive Guy☯️⚡ - 8mo
This is why.. "Maybe Daniel" it depends on the client visualization.. now I get it. 👀 nostr:nevent1qqsgss7yzmructr4nl68lktxx4wc42m3h3k25lqpj2d845z4cmkjlyspp4mhxue69uhkummn9ekx7mqzyrhxagf6h8l9cjngatumrg60uq22v66qz979pm32v985ek54ndh8gqcyqqqqqqgszf53c
Suhail @Suhail - 8mo
Public shaming clients making it hard works
LOL, that's not a button. It's my banner. 😁
It’s a mess. We only need one name on here. I think primal got this right, at least the display of it.
utxo ⚡🫂 @utxo ⚡🫂 - 8mo
Yikes
Yes, it is.
We need relays to block metadata events with "username", "handle" and "displayName" fields by default on https://relaying.io/, sir.
yunginter.net @yunginter.net - 8mo
isssue isn’t that they should have the right to display it how they want… there should be a preferred_name tag so a client could choose to respect that, currently they don’t know what editor you used, and don’t know how it was presented (because the field label is never the actual tag) and the expectation that sets.
Me and my 3 clients about to fix nostr
I was being facetious about them being in kind0. Its the result of anything goes without constraints at the relay or client level. We already have NIP32 for labeling to accomodate some of these and the core of kind0 should be streamlined for consistency
Since you don't have a lightning address I can't tell if you're joking or just new to nostr. But there are hundreds of relays, maybe thousands, it's doing well on that front 🫡
