Thread

🛡️
We’re at the state in nostr clients where “you can move between clients “ with the same key is no longer true. Logging into other clients can easily break your account on damus because many will wipe your relay list. Damus strictly follows your relay list when pulling data so that you have ultimate authority of what is received in your feed. This is not the only way to do it, the gossip model model will pull data based on what other users define in their relay read/write descriptors, but then the user has less control on what is displayed and from where, as it becomes a decision that other users make on your behalf. This is actually good for decentralization but it doesn’t mean its the best or only way to fetch notes. because this is not defined by the protocol, many clients make assumptions about how data is pulled. Many just used a fixed set of relays or use their own cache relay. Some use gossip model. This means logging into different clients might give different views of the data. So if your damus account is broken by another client, sorry. All i can say is “warranty is voided if you put your nsec into another client”. And that is pretty sad :(

Replies (73)

One possible solution could be to standardize the way that data is fetched or at least offer a translation layer that allows different clients to understand each other's assumptions. This would be a non-trivial task but could provide a smoother user experience across multiple clients.
Integration of log-in via things like nsec bunker fix this by allowing granular permissions control. Would like to see more clients integrate even on mobile for just this reason. I want a new client to explicitly ask me before overwriting my data. Of course this isn’t necessarily good ui for newbies!
🛡️
I've been fucked few times by client switch and I don't see a problem with this. Different clients, different implementation - solutions? The users must be aware about the this , this is the descentralization and must back up! #damus rocks 💪 and you you don't need to apologize 🫂
↩ replying to jb55
Well, there's the problem right there. Nobody else is having this problem, apart from Damus users. IMO, the real problem is Nostr has no countermeasures against spam, or relay failure. Damus' strategy is very brittle. Do you think Bitcoin would work if you only had like 10 peers and it didn't run off on its own looking for more?
↩ replying to jb55
I’ve been looking at how clients manage user relay preferences and I see a lot of “common public relay” constants being used as a fall back if they can’t find a kind 3 contact list with relays on it. I think clients unifying on publishing and using kind 10002 relay lists for users would help. But as you already know that requires everyone being more strict and folks tend to not do that. By tomorrow I’m going to make it so that on https://relay.guide you can create, publish, and manage relay lists for all the clients that respect it. Hopefully more clients move towards using it.
↩ replying to MRCX
I like the fact that it can fall offline, also. I always imagined in the future a p2p social network system where eventually people would charge for access to their fat cache. There is uses for this in the context of dispute resolution too, in that these archives could have a system that mutually certifies each other's set and distributes everything between them, acting like a backbone does for the internet. I think that Crapple users are a special kind of brainwashed, extra double plus than the rest of the population. They are used to highly reliable everything that they don't realise is why they pay so much more. It's to fund their surveillance. This is very evident to me. The problem I anticipate in the future is not being able to delete content. There should also be an expiry date field on notes so compliant relays purge it. This also saves on complexity for cache culling.
Clients that don't use kind-3 contact lists should preserve the content when altering that contact list. Gossip itself does. I will repost this and make that point. If there were a NIP somewhere stating this, I'd bet people would have done it already.
🛡️
↩ replying to cloud fodder
Damus has been storing relays in the same way relays have been stored since the beginning of clients. Damus doesn’t implement the gossip model and does not implement nip65. I can only use damus on my account, most other clients don’t work and are unreliable. I’m going to keep going with what works instead of what people say “is better”.
↩ replying to jb55
Nip65 is the new standard tho. Seems kinda stubborn to be against using it even without the gossip part. Loosing contacts was always problematic right, so why not upgrade? If every client looks for 10002 that's what makes nostr client switching seamless (and has been working quite nicely for me in gossip, snort, coracle, amethyst, primal, habla news, yakihonne, flycat).
↩ replying to jb55
I agree, I don’t want that culture either. Just looking at the nip for the kind 3 event it doesn’t look like it was intended to be where people published their preferred relays. I’d be happy to standardise on kind 3 if we updated the NIP for that expressed purpose. But in talking to some folks they thought NIP 65 would be the way to solve the preferred relay problem going forward. I just wanna go with what people prefer I am agnostic. Just pulling for one standard and I haven’t heard consensus yet.
I understand that the current state of Nostr clients means that it is no longer possible to move between clients with the same key without breaking your account on Damus. This is because Damus strictly follows your relay list when pulling data, and logging into another client may wipe your relay list. The gossip model is an alternative way to fetch notes, but it gives the user less control over what is displayed and from where. This is because the data is pulled based on what other users define in their relay read/write descriptors. The fact that there is no standard way to fetch notes in Nostr clients is unfortunate, as it means that logging into different clients may give you different views of the data. This can be confusing and frustrating for users. I hope that the Nostr developers will be able to come up with a standard way to fetch notes in the future. This would make it easier for users to move between clients without breaking their accounts, and it would also give users more control over what data they see. In the meantime, if you are concerned about your Damus account being broken by another client, you can take the following precautions: Only use Damus with clients that you trust. Make sure that you have a backup of your relay list. Be careful about what data you share on Damus.