NIP-24: Prevent Data Deletion in Replaceable Events

[Giszmo]

[Giszmo]

In the nip itself I did not mention the ugliness of actually ensuring to have user interaction before deleting stuff. If I developed a chess client that stored the user profile in 10101 and now a user happens to have some encrypted blob of data there, how should my app react? To just replace it as if it were a normal update of the user profile is what apps are doing now. Advertising to support this app means that this should never happen but what else should happen?

• Tell the user that there is some weird data and ask for permission to overwrite it, resulting in an edit war between two apps if the other app is still in use?
• Use the next higher kind until one is found that has no bogus data?
• Should overwriting other apps' data an option at all?

At the very least I hope with this nip to get devs to stop dropping properties of events they generally handle as in "Alice" case.

[fiatjaf]

I like the name "Protect the Unknown" and I would very much love to see this feature implemented, but I think it is a tricky one to get right when implementing things.

That is to say I shouldn't trust a client to not replace my events even if it claimed it wouldn't. Ultimately I would have to not use any client unless I really knew what it would do and was happy with that, which requires manual inspection.

But I like this NIP nonetheless, even if it only serves as a way to point to client makers how they are bad.

[Giszmo]

I like the name "Protect the Unknown"

I'm for changing the nip name, too. Also for reasons you get into below ...

and I would very much love to see this feature implemented, but I think it is a tricky one to get right when implementing things.

That is to say I shouldn't trust a client to not replace my events even if it claimed it wouldn't. Ultimately I would have to not use any client unless I really knew what it would do and was happy with that, which requires manual inspection.

But I like this NIP nonetheless, even if it only serves as a way to point to client makers how they are bad.

I agree completely. There can be very subtle details about data. If the client dev doesn't think of sorting being relevant, he might add tags that are referenced by index in the content to mention an obvious one.

Changing the name to "Protect the Unknown" would emphasise how this is not all to serious about implementation details but more a reminder to be kind to other projects. Client/Relay devs come here and build their checklists from nips and it's easy to forget that we are building stuff that should be interoperable in many ways. I'm not sure if this nip will end up as more than a reminder but a reminder nevertheless is important as existing projects already destroy the unknown a lot.

[fiatjaf]

@Giszmo do you want to revisit this?

[cameri]

There's a few typos (NIO instead of NIP).

I like this NIP but other than requiring confirmation it doesnt offer an interoperable solution on how a client can detect they'll overwrite existing data.

Im not sure there's a simple scalable answer to that either without clients having to add some metadata to replaceable events.

Clients should make it clear which NIPs they support too but that's not a thing today.

[mikedilger]

It seems that (ideally) this should be mandatory, however...

What if there is an event out there that I am replacing, but I didn't know it was out there? All I can do is make a best effort.

This might be why secure scuttlebutt linked events in a chain [Also, because I can never know if I have all the past events].

Other than that the NIP looks good to me.

[fiatjaf]

I think this is ok as just a recommendation we can point to. Nothing can ever be guaranteed.

Another mitigation technique that just came up to me is: to have relays (or some relays that decide to, or maybe just relays designed to serve as personal storage servers) store multiple versions of kind-0 events and then some clients can present all these to the user and allow the user to pick one (then republish that with the current date) or even merge the data from multiple.

[Giszmo]

So clients hopefully consider this issue but it will ultimately be users and third party listings that will judge if a client plays nicely with other clients.

@Cameri I fixed the NIO typo. If you found others, please code-review and suggest fixes.

[monlovesmango]

@Giszmo in your opinion, if a client is making best effort to abide by this NIP would that include first querying for the kind they are saving? If so should that be recommended in this NIP as well?

[cameri]

Agreed. I didn't know this either and for a while nostr-ts-relay did not treat kind 3 as replaceable.

Ricardo Arturo Cabral Mejía

Sent from ProtonMail mobile

-------- Original Message -------- On Nov. 26, 2022, 12:46 p.m., monlovesmango wrote:

@monlovesmango commented on this pull request.

---

In 24.md:

@@ -0,0 +1,57 @@ +NIP-24 +======

+Protect the Unknown +------------------- + +draft optional client author:giszmo + +## Replaceable Events + +A replaceable event as defined in NIP-01 and NIP-16.

yes but nip-01 does not define them as a replaceable event. was pretty confusing to me but just my opinion. i know kind 0 and kind 3 are replaceable, but nip-16 explicitly defines what we consider to be a "replaceable event". if we want to use terms like this we should be clear on the definition and not use it in different contexts in different nips.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[Giszmo]

@Giszmo in your opinion, if a client is making best effort to abide by this NIP would that include first querying for the kind they are saving? If so should that be recommended in this NIP as well?

I would assume the client to be subscribed to that kind anyway as it's relevant to the client.

[Giszmo]

Absent vetos within 24h I would merge this.

[monlovesmango]

does this cover nip 33?

[Giszmo]

does this cover nip 33?

@monlovesmango in spirit it did. Now it does explicitly. The nip is a reminder so I hope updating it in the future doesn't turn into a burden.

[staab]

I think this goes more under "best practices" than "protocol definition". There's been some discussion about how to design events going forward to avoid too many conflicts like this, but I think at the end of the day client developers will figure this out or gain a bad reputation as a result of stomping people's data, I don't think it's something for the protocol.

Closing due to inactivity, re-open if desired.