Nostr Web Client

Hm. What about:

- determining a nip, which requires the relays to delete and not share to other relays and have the means to do so.

- informing the user whether the picked relays comply or not.

- implementing a function that only a person using relays that have implemented the nip can also receive a note that has been send with that assumption.

Would that not achieve the effect we are discussing. We can leave out the discussion of someone taking the information and publishing it somewhere else. That happens on Twitter and anywhere else.

No?

balas 2y ago

nop, once a user receives a note from a relay, there's no asking it back. so if I subscribe to you via relay A, and I receive your note, then when you issue your "delete" event to relay A, I already have your note, and if I then ignore your delete event, there's nothing you and relay A can do and I can send it to relay B that won't delete anything.

Reply to this note

Please Login to reply.

Discussion

nobody 2y ago

Both scenarios do not contradicts my suggestion but are rather the risk anyone has right now also on Twitter.

Actually, in the first of your scenarios the data would be still on relay a when you view it. So it is not stored on your client if I am not mistaken. Deleting it, would still make it disappear, no?

balas 2y ago

clients can have their own db. they're not "automatically" synced with relays. twitter is different because it's just one client with one harcoded relay, so they control the whole experience on what to serve, but if someone screenshots the tweet, twitter can only try to remove those images, but the content is out there for anyone to see.

nobody 2y ago

But then you just need to extend the nip to the client and require the relay to not give out the note unless the client complies. No?