pull down to refresh
0 sats \ 11 replies \ @thrown 5 Jul 2022 \ parent \ on: Damus is a Nostr client with Lightning ⚡️ integration nostr
Yes, the client code can be told to delete the data. The fact that someone could alter their client to ignore these rules doesn’t mean that you should ensure that everyone ignores them lol.
Right to be forgotten could be implemented in multiple ways, but you simply don’t care and you’re not interested. Which is why these types of products fail. Because the people that make them don’t care about UX.
The right to be forgotten is pointless if you can't ensure that the data is sure to be deleted. It's not a UX problem.
reply
Again, there are ways that you can do this, but you simply don’t care. You’ve just resigned to accept a subpar UX. It’s as if you have contempt for your users or something
reply
You keep repeating you can do this, but never explain how.
reply
i’ve said how but you are unwilling to compromise on anything. you think if there can’t be 100% guarantees (impossible because we are dealing with humans), then it’s not even worth considering
reply
That's true. If you believe otherwise, ask yourself why this has not been done before.
reply
It has been done and it is being done. Just not with Nostr
reply
You keep saying things without backing them up. Just stop or throw concrete examples. I'll stop replying until you do.
reply
-
an architecture that does not imitate dead drops. firstly you would need a fundamental design change so that nodes don’t become the owners of the actual content that users post to them. in other words, dumber nodes. this will never happen on Nostr in particular.
-
something like Vitra where we can know if users misbehave but cannot stop them from doing so. in a human network this seems ideal to me. like in real life, if someone does something to destroy your trust, you get burned and you move on. you just don’t interact with that person anymore. the key is knowing when you get burned.
-
utilizing a heavier blockchain style system with zk-proofs to ensure that certain operations cannot be done. this is far too heavy imo, but if someone for some reason needs 100% guarantees, then i guess it’s the path they would prefer.
I think 95% of people would be perfectly comfortable with option 1 (maybe 2). You explain in the docs that it’s possible for someone to hack their client app and save things that are supposed to be deleted. The user realizes that none of their friends are weirdos and they are ok with that.