Vitor Pamplona @Vitor Pamplona - 1y
Mostly because those fields names were never part of any NIP. They are all ad-hoc.
The: Daniel⚡️ @The: Daniel⚡️ - 1y
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.
3bf0c - 1y
"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.
Vic @Vic - 1y
How so? client choice
Why not also "handle", "nickname", "display", "DisplayName", "nick_name", "user_name", "user", "Name"?
Why can't we all just agree on a single field instead of polluting everybody's kind0, increasing bandwidth usage of everybody and making the logic of every client much more complex? The only point of having a standard is not having to support every different bizarre implementation people come up with. nostr:nevent1qqsdhveyzt5e4ssss2fgvtxp03ax7yhnpdyqqu6f6kku49fsy56p72gpzamhxue69uhkzarvv9ejumn0wd68ytnvv9hxgtcpzpmhxue69uhk2tnwdaejumr0dshsz9nhwden5te0v4jx2m3wdehhxarj9ekxzmny9uq3uamnwvaz7tmxv4jkguewdehhxarj9e3xzmny9acx7ur4d3shyqtxwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx2tmwwp6kyvtpxdc8vam9xfcrxa3hd4hx573kdpkx2d3nwgmrywrhdsuhwdfkxashwdm4xgekv7n3wvcrvvnkx4m8zcm3w96nxum8dqen7cnjdaskgcmpwd6r6arjw4jszrnhwden5te0dehhxtnvdakz7qguwaehxw309ahx7um5wgkhqatz9eek2mtfwdhkctnyv4mz7qg7waehxw309ahx7um5wgkhqatz9emk2mrvdaexgetj9ehx2ap0qyg8wumn8ghj7mn0wd68ytnddakj7qg3waehxw309ahx7um5wgh8w6twv5hszynhwden5te0dehhxarjxgcjucm0d5hszxnhwden5te0wp6hyctkd9jxztnwdaehgu3wd3skuep0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgkwaehxw309aex2mrp0yhx6mmnw3ezuur4vghsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshszgthwden5te0wfjkccte9ehx7um5wghxyctwvshhyetnw3exjcm5v4jqz8nhwden5te0wfjkccte9ehx7um5wghxyctwvshhgun4wd6x2eqpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhszxrhwden5te0wfjkccte9ecxcetzwd68ytnrdakj79yusvu
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.
utxo ⚡🫂 @utxo ⚡🫂 - 1y
Yikes
Yes, it is.
We need relays to block metadata events with "username", "handle" and "displayName" fields by default on https://relaying.io/, sir.
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 🫡
