wakoinc on Nostr: I tried a new Nostr mobile app last night and today I realised it’s dropped my ...
I tried a new Nostr mobile app last night and today I realised it’s dropped my Damus kind3 content data - which stores relays. I now don’t want to test new Nostr apps with my primary key 🫤
As a user, the experience was crap. The Nostr event diversity and quality I saw today was really different and far less than normal - I didn’t realise at first my relays had been dropped. As a user I may not have realised and never picked up Nostr again.
A similar issue happens around max following, where kind 3 gets too big and some relays reject it, leaving weird states.
Couple suggestions:
1. Can we add a max follow threshold in apps until we find a way to support more without these issues? Maybe 1200 seems to be ok.
2. Can we in general consider metadata update compatibility in NIPs better. For example, clearly stating “when updating kind 3, the content should be preserved”. Or “when updating kind 0, all existing content keys should be preserved unless explicitly removing them”.
We need to better consider data loss, and limit failures or bad experiences. Decentralisation is hard, but we are ignoring the easy ways to improve it.
And a final note too, when looking for metadata events (like profile or contact list) we should smartly query all profile suggested relays for any existing data. I suspect some apps just query hard coded relays… doh. You need to query NIP05 relays, kind 10002 relays, at a minimum - then any extra ones.
As a user, the experience was crap. The Nostr event diversity and quality I saw today was really different and far less than normal - I didn’t realise at first my relays had been dropped. As a user I may not have realised and never picked up Nostr again.
A similar issue happens around max following, where kind 3 gets too big and some relays reject it, leaving weird states.
Couple suggestions:
1. Can we add a max follow threshold in apps until we find a way to support more without these issues? Maybe 1200 seems to be ok.
2. Can we in general consider metadata update compatibility in NIPs better. For example, clearly stating “when updating kind 3, the content should be preserved”. Or “when updating kind 0, all existing content keys should be preserved unless explicitly removing them”.
We need to better consider data loss, and limit failures or bad experiences. Decentralisation is hard, but we are ignoring the easy ways to improve it.
And a final note too, when looking for metadata events (like profile or contact list) we should smartly query all profile suggested relays for any existing data. I suspect some apps just query hard coded relays… doh. You need to query NIP05 relays, kind 10002 relays, at a minimum - then any extra ones.