Oddbean new post about | logout
 nostr:nprofile1qqsqgc0uhmxycvm5gwvn944c7yfxnnxm0nyh8tt62zhrvtd3xkj8fhgprdmhxue69uhkwmr9v9ek7mnpw3hhytnyv4mz7un9d3shjqgcwaehxw309ahx7umywf5hvefwv9c8qtmjv4kxz7gpzemhxue69uhhyetvv9ujumt0wd68ytnsw43z7s3al0v has the best suggestion to approach profile fields imo 

Make the spec allow users to define their own fields instead of attempting to standardize them

https://github.com/nostr-protocol/nips/pull/1592#issuecomment-2488744571 
 That's a cool idea actually 👀 
 Standarization is required if you want clients to do something about the fields. If they are not doing anything (just displaying) then sure. 

PS: You can already write your list of labels and values on the About Me text. You can just add everything there.  
 We have the minimum amount of fields, like display name, image, lightning addr, bio, then just display things the user wants like pronouns or location or age or whatever 

This list would just get massive otherwise and likely have so much contention, and still have interoperability issues when some clients do something with a field and others don't  
 The issue is that if clients are doing something with a field, it should be listed and upgraded on the NIP. 

There are over 30 fields or so that I have seen on Kind 0s that are not listed there. And it is fine. I am not sure what the extra array does that the current field list wouldn't do. 
 It creates a clear distinction between user-defined fields and protocol fields. User-defined fields are only for display (and only for display in a confined region of the profile), while protocol fields can actually influence the behavior of the account, like set your Lightning address or avatar.

User-defined fields are an amorphous blob the user can do whatever they want with but should not be relied upon in any way, kind of like pronouns. 
 Right, so if pronouns are just listed as a field when the user visits a profile, it works. But if they are added after each person's name in the feed, then it becomes something else.  
 Love this solution tbh 
 Honestly, I could see the argument either way.  Take the 'website' field for example: it's not a field I personally really care about; but, I suspect there are enough people who do to support it being standardized.  Otherwise, users could be forced to maintain both the customized 'website' field that some popular apps choose to use AND the customized 'URL' field that other popular apps choose to use. 
 This field has tripped up a number of folks bc it is distinct on Primal and not on other apps, so if a user enters their website on Primal thinking it will populate across the network, they will find that it doesn’t. 

Most protocols have standards, it would be helpful to get a baseline established for things like profile and kind 1 notes as well as links.  
 I really like this approach. this does not cover any standardization about what "type" the field is. but maybe thats a good thing? 
 Alex's profile is based and then he does the vegan thing where he let's you know he's vegan. Lol.