Clients shouldn't override extra fields though, that's bad implementation.
Discussion
Yeah that sounds like clients who do this are broken.
There is should and there is reality.
Yeah totally. My lightning address and other profile data were never overwritten since I started using nostr though.
True but I think most clients implement zaps so that’s a field they all care about.
We certainly have this overwriting problem with kind 3s.
Part of the problem is the kind 0 spec is scattered over a ton of NIPs. There is NIP-01, NIP-24, NIP-57, and I imagine others that reference profile fields but can’t find anywhere to see them all in one place.
…with that being said, I totally understand why you want to put it in kind 0 and I don’t think it’s the end of the world. Just might face some challenges until it’s more widely adopted.
not really, an event is an event
this is a general problem with the implementations at present, replaceable events cause previous versions to be deleted by relays and what they SHOULD be doing is just returning newest ones and allowing clients to request older versions
i've made an issue about this and nobody is really taking it seriously at this point
I'm on team "replaceable events are bad". nostr:nprofile1qywhwumn8ghj7mn0wd68ytndw46xjmnewaskcmr9wshxxmmd9uq3qamnwvaz7tmwdaehgu3wd4hk6tcpz4mhxue69uhkummnw3ezummcw3ezuer9wchsqgzsm98u9kzcp35zkpc62shck8335gqtq5yt4w26xwl0pp2a72qavvkw9mkh race conditions frequently happen regardless of client implementation, where a stale version forms the basis for an update. The more attributes on kind 3, the more potential for race conditions.