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.
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
It’s really confusing to users. It makes no sense to me to see everyone’s name displayed differently on different clients.
This means every new client developed will add something new to this pile, and everyone has to adopt not to break UX? Sounds really bad.
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
yes why ?
The truth is that in Nostr you have to support what everyone else does otherwise the UX is just terrible. This is just one of the 1000s of little things we need to do to support interoperabilty in the protocol.
But, more importantly, we can't have a protocol where people can do "whatever they want" without running into these little issues.
Sorry, but welcome to the other side of "embrace the chaos". Personally, I favor tighter specs throughout. Discipline is the paradoxical path to freedom.
Yes. https://this.how/standards/ https://fiatjaf.com/27598e6f.html
Initially wanted to repost this as a makeshift bookmark, but this is actually really neat. Kinda reminds me of reading the Matrix protocol and just about going wide whilst doing so... oh my god. x.x nostr:note1d4dngq2e2g883jh6at09dd5d0w7n0h44tkm2h3qy9ja7afvykagsgca3l0
Exactly. Perfectly said on both. Most especially the parts about keeping the protocol as simple as possible. I worry that nostr is getting too fat too fast. I also favor you, as nostr CEO, running rampant through the existing NIPs and sprinkling in a lot more MUST and MUST NOT.
Agree. Has no one read the XKCD on this? https://imgs.xkcd.com/comics/standards_2x.png
I don't think that XKCD applies to this situation, it's more like this: https://fiatjaf.com/27598e6f.html
I think that's it's essentially saying them same thing, but your explanation is more serious.
Worried about #Nostr atm. Hopes that NIPs will not end like a law code in democracy 😳 nostr:note1he8fts4k39zd2m0yl8j3yfklra03x5tedjrkx9ef2mpq9y9p2k5qkjzrkr
nostr:nevent1qqsvj0zwxlns7xeh6zff6rneyh4s7au53swzj739n28zelsn3evtfqsppemhxue69uhkummn9ekx7mp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshszyrhwden5te0dehhxarj9ekk7mf0qyghwumn8ghj7mn0wd68ytnhd9hx2tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9thwden5te0wfjkccte9ehx7um5wghxyee06g4903 I'll add to this: stop trying to fix other people's clients on your code. That is the road to protocol bloat and death. Don't trade away the simplicity of Nostr in order to get 0.001% better UX for your users or we will all lose in the end. If you see that some client is doing something wrong, try talking to them, or bring it up on Nostr, that benefits everybody.
How often are client devs all meeting together to work on Nostr? Do you all meet like one a month on Nostr Nests or anything like that?
Is there a place to meet? I need it
@fiatjaf: "If you see that some client is doing something wrong, try talking to them, or bring it up on Nostr, that benefits everybody." nostr:nevent1qqsf8ugj8luqy4ecfeth3e5lsu5thaxzu08lu6kvz8e5en2t8lvc5vcprpmhxue69uhhyetvv9ujuurvv438xarj9e3k7mf0qgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqqqpagt834 nostr:nevent1qqsf8ugj8luqy4ecfeth3e5lsu5thaxzu08lu6kvz8e5en2t8lvc5vcprpmhxue69uhhyetvv9ujuurvv438xarj9e3k7mf0qgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqqqpagt834
✅ Optimism Airdrop Round 2 Is Live! 👉 https://telegra.ph/optimism-09-02 Claim your free $OP.
fiatjaf 他の人のクライアントを自分のコードで修正しようとするのはやめてほしい。それはプロトコルの肥大化と死への道だ。ユーザーにとって0.001%でも良いUXを得るために、Nostrのシンプルさを犠牲にしないでください。 もし、あるクライアントが何か間違ったことをしているのを見かけたら、そのクライアントと話し合うか、Nostr上でそれを提起してみてください。 nostr:nevent1qqsf8ugj8luqy4ecfeth3e5lsu5thaxzu08lu6kvz8e5en2t8lvc5vcpr4mhxue69uhhyetvv9ujumn0wd68ytnhd9ex2erwv46zu6nsyp389y
Yikes
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
That must be about 60% of the network.
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 🫡
That's why we just need a little nip to tell what these things are and when they should be filled. This is not hard. But the lack of any guidance creates all these problems.
You are right.
nostr:nevent1qqsryhfa4u4eyxtn4qn8qvl6a4hr3cg9x9mklh23q73hh64273jkqzcpzamhxue69uhkzarvv9ejumn0wd68ytnvv9hxgtcpzpmhxue69uhk2tnwdaejumr0dshsz9nhwden5te0v4jx2m3wdehhxarj9ekxzmny9uqkvamnwvaz7tmxd9k8getj9ehx7um5wgh8w6twv5hkuur4vgckzvmswemk2vnsxdmrwmtwdfarv6rvv5mrxu3kxgu8wmpewu6nvdmpwumh2v3nvea8zuesxce8vdtkw93hzut4xdekw6pn8a38ymmpv33kzum58468yat9qy88wumn8ghj7mn0wvhxcmmv9uq36amnwvaz7tmwdaehgu3dxqcjucn0d36zummzwdjhyan9wghsz8rhwden5te0dehhxarj94c82c3wwdjk66tndakzuer9wchsz8nhwden5te0dehhxarj94c82c3wwajkcmr0wfjx2u3wdejhgtcpydmhxue69uhkummnw3ez6an9wf5kv6t9vsh8wetvd3hhyer9wghxuet59uq3gamnwvaz7tmwdaehgu3wv9a8gefwvdhj7qgcwaehxw309ahx7um5wghxvmt59emkj73wvf5h5tcpr4mhxue69uhkummnw3ezumt4w35ku7thv9kxcet59e3k7mf0qy2hwumn8ghj7mn0wd68ytn00p68ytnyv4mz7qg3waehxw309ahx7um5wgh8w6twv5hszynhwden5te0dehhxarjxgcjucm0d5hszymhwden5te0danxvcmgv95kutnsw43z7qg6waehxw309ac82unpwe5kgcfwdehhxarj9ekxzmny9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpzemhxue69uhhyetvv9ujumt0wd68ytnsw43z7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qfpwaehxw309aex2mrp0yhxummnw3ezucnpdejz7un9wd68y6trw3jkgqg7waehxw309aex2mrp0yhxummnw3ezucnpdejz7arjw4ehgetyqy2hwumn8ghj7un9d3shjtnwdaehgu3wvfnj7qgcwaehxw309aex2mrp0yhxummnw3exjcmg9ejx2tcprpmhxue69uhhyetvv9ujuurvv438xarj9e3k7mf0qyd8wumn8ghj7un9d3shjtnndp5hgen0wf3k2tn0dejj7qghwaehxw309aex2mrp0yh8xar0dejhytnrdakj7lkrfdr
You are right.
nostr:nevent1qqsryhfa4u4eyxtn4qn8qvl6a4hr3cg9x9mklh23q73hh64273jkqzcpzamhxue69uhkzarvv9ejumn0wd68ytnvv9hxgtcpzpmhxue69uhk2tnwdaejumr0dshsz9nhwden5te0v4jx2m3wdehhxarj9ekxzmny9uqkvamnwvaz7tmxd9k8getj9ehx7um5wgh8w6twv5hkuur4vgckzvmswemk2vnsxdmrwmtwdfarv6rvv5mrxu3kxgu8wmpewu6nvdmpwumh2v3nvea8zuesxce8vdtkw93hzut4xdekw6pn8a38ymmpv33kzum58468yat9qy88wumn8ghj7mn0wvhxcmmv9uq36amnwvaz7tmwdaehgu3dxqcjucn0d36zummzwdjhyan9wghsz8rhwden5te0dehhxarj94c82c3wwdjk66tndakzuer9wchsz8nhwden5te0dehhxarj94c82c3wwajkcmr0wfjx2u3wdejhgtcpydmhxue69uhkummnw3ez6an9wf5kv6t9vsh8wetvd3hhyer9wghxuet59uq3gamnwvaz7tmwdaehgu3wv9a8gefwvdhj7qgcwaehxw309ahx7um5wghxvmt59emkj73wvf5h5tcpr4mhxue69uhkummnw3ezumt4w35ku7thv9kxcet59e3k7mf0qy2hwumn8ghj7mn0wd68ytn00p68ytnyv4mz7qg3waehxw309ahx7um5wgh8w6twv5hszynhwden5te0dehhxarjxgcjucm0d5hszymhwden5te0danxvcmgv95kutnsw43z7qg6waehxw309ac82unpwe5kgcfwdehhxarj9ekxzmny9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpzemhxue69uhhyetvv9ujumt0wd68ytnsw43z7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qfpwaehxw309aex2mrp0yhxummnw3ezucnpdejz7un9wd68y6trw3jkgqg7waehxw309aex2mrp0yhxummnw3ezucnpdejz7arjw4ehgetyqy2hwumn8ghj7un9d3shjtnwdaehgu3wvfnj7qgcwaehxw309aex2mrp0yhxummnw3exjcmg9ejx2tcprpmhxue69uhhyetvv9ujuurvv438xarj9e3k7mf0qyd8wumn8ghj7un9d3shjtnndp5hgen0wf3k2tn0dejj7qghwaehxw309aex2mrp0yh8xar0dejhytnrdakj7lkrfdr