One of the downsides of closed source apps is you can’t see what it’s doing or file a ticket to fix bugs. This just came up with me with @YakiHonne which has a bug where it overrides your contact list if you follow someone in the yakihonne app. Hopefully it’ll get fixed fast. In general we have a nostr problem with replacable list events and how easy it is for apps to override and whip out lists.
to be clear i’m really liking the ios yakihonne app. just frustrated that i lost my contact list.
https://metadata.nostr.com has saved my ass before.
They do have a telegram chat and are normally quite helpful. I'll post this note there. https://t.me/YakiHonne_Daily_Featured
"In general we have a nostr problem with replacable list events and how easy it is for apps to override and wipe out lists." 🎯 nostr:nevent1qqsr7mtxqvxfu38a30my4adptk9qvg8wjxnnch7fs7c7k8dnaf5v5xgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygrkcud2uwjfruweamz8ewshug5umfq38g9mkmn2u9mk6ajru2w2lgpsgqqqqqqs2llp84
I wouldn't put your private key into a closed source app.
Note: The older link for YakiHonne's app for iOS is no longer used, kindly remove it from test flight to avoid any inconveniences between app versions. New link: https://testflight.apple.com/join/tcXozZIu
Agree, replaceable lists are terrible. Also lost my contact list with a beta version of Iris a while back. Do you use https://metadata.nostr.com/ ? I got part of my contacts back that way
I was able to fix it with https://metadata.nostr.com/ and also found out that I was running an orphaned version of YakiHonne… The new TestFlight is: https://testflight.apple.com/join/tcXozZIu It’s a great app and really highlights good aspects of Nostr! Now can we get some $ from OpenSats or elsewhere to talk/bribe @Shaun in to open sourcing it. ;-D
It’s even worse with Primal which seems they are doing just their own thing on contacts / relays lists. But I agree this is a big problem. I noticed the unfollowing a profile is often not working in many clients. So the solution then is to add that profile to the mute list 🫤
Agreed. The nature of replaceable lists lacking version reconciliation in a decentralized environment makes for a major risk of data loss or clobbering. I’ve been stewing on the idea that old replaceable list events should not be deleted implicitly, and that there should be an additional tag for every new list event that indicates the event id of the old event it intends to “replace”. If a client encounters a series of events for the same list, it should allow the user to determine how to reconcile if there’s branches in version history. I’ll put out a PR to NIP-01 to see what people think but I imagine it could be controversial as it adds a layer of complexity.