141 sats \ 24 replies \ @thrown 1 Jul 2022
This is only true in the sense that you have the control to choose to hand over control to the nostr nodes.
After you post something to a node, you have zero control. The node effectively owns it at that point because only they can delete it.
I think users intuitively understand that if you can’t delete it, you don’t really own it.
I wish Nostr would get better PR around this. It can be useful for certain use cases, but not for public social media (maybe unless you’re posting completely innocuous things like “the sky is blue”)
reply
113 sats \ 18 replies \ @analogue 1 Jul 2022 freebie
The only way to be able to delete something that you made public in the past, is to exclusively host it yourself, at all times.
Such a feature is not compatible with any kind of decentralization.
reply
10 sats \ 17 replies \ @thrown 1 Jul 2022
This is a false dichotomy.
We both know that there are multiple different solutions, if people actually care about UX.
Soft-deletes is one option. Private groups is another option.
overall, I just don’t like the architecture. I’m more interested in decentralized networks that have forward secrecy and don’t assume that you want your data blasted to every corner of the earth. Again, that idea is useful for some things, but not for a normal social user imo.
reply
0 sats \ 16 replies \ @premitive1 3 Jul 2022
Could we encrypt the data in a way that to unencrypt it one would need current permission from the originator? This way it lives in the network, but only included parties can actually view the info.
reply
13 sats \ 15 replies \ @thrown 3 Jul 2022
Yeah that is the “private group” idea.
Your data is encrypted and all the nodes are doing is passing around decryption keys to the people that you want to see it. So the nodes just pass keys and pointers to data rather than data itself.
But NOSTR architecture simply doesn’t allow this kind if thing. It’s not what it is built for.
reply
0 sats \ 14 replies \ @premitive1 4 Jul 2022
I thought the inverse. Nodes could distribute the data, so it can have redundancy, but you directly give decryption keys to those who you actually want to give access to viewing the data.
reply
0 sats \ 13 replies \ @analogue 5 Jul 2022 freebie
But again, once a client has the encrypted data and the decryption key, you cannot make them forget those 2, and thus you cannot delete your data.
This idea that "right to be forgotten" can be implemented in a decentralized solution is false.
32 sats \ 4 replies \ @k00b 1 Jul 2022
It's definitely semantics, but nostr nodes only own a copy which AFAIK is known to be a copy because it's signed by the owner. If you want to say something you're afraid of being associated with you can always use a one-time pubkey, can't you?
reply
0 sats \ 3 replies \ @thrown 1 Jul 2022
why wouldn’t the nodes hold a read-key to the original, rather than a copy? That way the owner can at least revoke the read-key AKA tombstone their data on the node.
reply
0 sats \ 2 replies \ @analogue 5 Jul 2022 freebie
There is no difference between the original and a copy in a digital world.
101 sats \ 0 replies \ @cryptocoin 1 Jul 2022
iOS only :-(
reply
11 sats \ 0 replies \ @Coinosphere 2 Jul 2022
Gorgeous! Needs Android ASAP.
I'd also love to see a detailed security audit but knowing nostr it's probably the best out there already.
reply
1 sat \ 0 replies \ @KingZing 1 Jul 2022
Been looking at this just a few days ago. Surprised they are prioritizing apple first
reply