Replying to Avatar Sherry

#NOTD THE NIP OF THE DAY 2

https://github.com/nostr-protocol/nips/blob/master/02.md

Here is where our contact lists are stored! KIND-3.

{

"kind": 3,

"tags": [

["p", "91cf9..4e5ca", "wss://alicerelay.com/", "alice"],

["p", "14aeb..8dad4", "wss://bobrelay.com/nostr", "bob"],

["p", "612ae..e610f", "ws://carolrelay.com/ws", "carol"]

],

"content": "",

...other fields

}

Most of the clients use this as "following". They search among all relays, find the latest Kind-3 event signed by your npub.

When you click follow on someone's profile page, the client generate a new event, add that name to tags and publish a new event.

Relay should delete the previous contact list once they recieved new one, which, not always happen.

## Why do we suffer from contact list disaster?

Client fails to find the latest contact list event and adds the new following at the end of the lates previous event they can find, and add the current timestamp to it. This is why we feel our following list being wiped.

## Why is follower number never unstable?

Followers are calculated from querying everyone's latest kind-3 event. Based on different client implementation, "everyone" is an unstable set, also, as we mentioned above, "latest event", may be stored in a relay we didnt know.

Thank you for reading. I hope this will help you know a little bit more about some weird client behaviours and enjoy the design behind nostr.

idea cr: nostr:npub1t3ggcd843pnwcu6p4tcsesd02t5jx2aelpvusypu5hk0925nhauqjjl5g4

Day 1 here

nostr: note13g8da56ltev50p2wtl96rj6qvu43p5jqsm3u2x3ylw6nzqztfxdsnhzj2k

Reply to this note

Please Login to reply.

Discussion

No replies yet.