nips
nips copied to clipboard
nostr-protocol
Metadata. Kind:0 Profiles.
Clients are keeping profile information above and beyond the NIP-01 metadata in kind:0.
Users are likely to use more than one client and do not want the kind:0 sent by one to collide destructively with the other.
Users are probably going to want their primary profile to be kept in just one of their clients. They'll expect the other clients to accept and remember the parts of that profile that they can understand. Users will also expect that the fields in a client are not erased by a kind:0 event that doesn't have those fields.
Example: Damus has a field for a lightning address. More-speech does not. When more-speech sends out a kind-0, it does not include a lightning address. Damus should not erase the lightning address when it receives that kind:0. When Damus sends out a kind:0 it should include all the fields it knows about, including the lightning address. More-speech should ignore fields it doesn't understand.
I suggest that NIP-01 should recommend this behavior.
As an aid, we should provide standard names in NIP-01 for fields that have become common amongst the clients.
e.g. (from Damus) name:, display_name:, about:, picture:, banner:, website:, lightning:, nip05:.
Coracle merges kind 0's as they come in and re-publish the whole enchilada, however I'm not sure that's a complete solution, since I believe relays treat kind 0 as a replaceable event, meaning clients won't receive a stream of events, just the latest one.
Right. I think the persistence of fields is going to have to be the responsibility of the clients.
I think clients need to support all fields they don't know about. They don't have to know what they mean, and strictly speaking they don't have to support editing of them, but they must preserve them. So serializing/deserializing into a known struct with known fields isn't viable (unless you also have a catch-all map field too).
Ideally clients would allow users to create new metadata fields with any field name the user chooses. Fields with non-string contents probably need to be handled specially, but string-valued fields can be handled generically.
Ideally clients would distinguish between blanking out a field and removing it all together.
Perhaps what we are looking for is the cookie model. Kind:0 contains a set of standard fields as described by NIP-01 and then each client can add and access their own cookies. Each client should preserve the cookies of other clients when they send a kind:0.
Example: {name: <username>, about: <string>, picture: <url, string> cookies: {damus: {..damus-fields...} more-speech: {...more-speech-fields...}}}
I don't think kind 0 is for client-specific data, I would prefer to put those in an encrypted replaceable note with a d tag.
Interesting. It hadn't occurred to me that the client specific data might be private. Of course a client could encrypt any part of their cookie that they think requires privacy.
And putting it in kind 0 increases the contention over the event, leading to more race conditions (clients might want to update settings frequently). It would also increase the bandwidth use, since kind 0's are broadcasted more widely.