Mostly because those fields names were never part of any NIP. They are all ad-hoc.
Discussion
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.
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
While we are at it. Let’s appoint you as the lead nostr PM. We need some strategic guidance.
More than happy to help since that’s my actual job at the Fiat mines.
I think we need Jira on nostr. 😆
Man, you need Steve Jobs to manage the nostr devs. I’ve seen how they discuss implementation. 🤣🤣🤣 I would fail getting them to agree on anything.
"name" is on NIP-01. Why can't we just use that?
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 so bad.
How so? client choice
Why not also "handle", "nickname", "display", "DisplayName", "nick_name", "user_name", "user", "Name"?
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.
You must be trolling so I will start ignoring you.
Why would you like to add those things?
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
Yikes
We need relays to block metadata events with "username", "handle" and "displayName" fields by default on https://relaying.io/, sir.
