nip-09 delete events SHOULD be retained as long as possible, and other minutiae

[mleku]

I needed to check to make sure that it hadn't been defined as an ephemeral event, because it is not an ephemeral event.

It should be noted in the spec that it is a tombstone meaning that it should not be deleted until a consensus agrees that all replicas do not have the record anymore. So, in other words, it should be in the list of the few things that an event store should never delete, until there is only such items left to remove.

Consequently also, there should be a "SHOULD" clause in there stating that due to it being a tombstone and that in the absence of a consensus that can be 100% certain about deleting, that relays SHOULD retain delete events as long as possible.

It is a given that all events are in the public domain and no recipient can be forced, only requested, to actually delete the data, and human error also dictates that even then, some amount of time should pass before the operation is done. And lastly, it should be deferred for purely hardware-bound limitations of data storage, namely that on solid state storage such as NVMe drives, deleting blocks of data in actuality is equally diminishing the total lifespan of the media and it is more cost effective to use a deleted marker until that space is needed again. This is in part implemented using the TRIM operation as well, but even still, it does need to be pointed out that for a relay operator, the delete operation costs their resources as much as the save operation.

[mattn]

Tombstone is a method that can be used only for a finite range of distribution and can garbage collect deletion records when the deletion command is distributed to all data replicas. However, Nostr is unable to know which relays have been published with the record wanted to delete. In other words, it cannot garbage collect deleted records forever. I recommend physical deletion as an alternative.

As I explained at https://github.com/nostr-protocol/nips/pull/1413, I believe that who signed the event should have a regular way to delete the event completely on their own. It is clearer and simpler that way.

[mattn]

For example, snort.social have a paid relay, but was previously a free relay. To remove that old event from the snort relay, you must charge for it. IMO, all of the relays MUST provide way to delete the event which is signed by the author freely, I think.

[mleku]

I recommend physical deletion as an alternative.

So, the user is going to get in a plane, fly to the data centre where the relay is operated out of, just jump on the terminal, send a command to the database to delete the record? And they won't get stuffed in the back of a security guard's van and carted to the police to be charged for tresspassing let alone tampering with data (that's called wire fraud i think).

"physical deletion" is not in the available options for users for this case.

A tombstone, however, that will match on a search, will allow a client to hide the result EVEN IF IT COMES UP ON ANOTHER RELAY from the user.

What exists is fine, i'm just saying that the wording of it needs to make it more lucid so that nobody misunderstands that "physical deletion" is a courtesy and not something that can be forced on the persons storing said data on behalf of the user.

No amount of stupid words are going to change the tactical and strategic reality of information security. You sent it out, you are in the hands of those you sent it to, and they can send it on, in microseconds, and before you know it, the whole world has a copy of your signed event.

This is reality and even centralised systems do not in fact prevent this one-way path of data.

[mattn]

Most social networking services assume that you have signed a data license agreement when you use their services. And those services provide a way to completely delete your data. Why doesn't Nostr have a way to completely delete historical data? Is it because of distributed thinking? If so, that is not a reason.

[vitorpamplona]

IMHO,

1. Delete events should be stored forever to avoid re-broadcasting a deleted event back into the relay.
2. If we move forward with https://github.com/nostr-protocol/nips/pull/1256, the account deletion events should be stored to avoid any past post to show up again.
3. When a delete account event shows up, the relay can delete all the individual deletion events from its database and tombstone.

[mleku]

@mattn We are not in the business of running a company under any specific jurisdiction here. You can offer such a service in the name of your government registered corporation, in fact, in most places you will be compelled to.

The specifications and stipulations in the protocol are purely guided by practical principles of information security and the necessities of distributed systems. They are not legislations, they are natural laws emergent from the properties of the systems we build.

@vitorpamplona it is pleasant to say I agree on all three points.

Although i would argue that the account deletion event should also be a tombstone and persist more or less indefinitely in case of a key breach, to ensure such events are never accepted. This is a complication for relay implementation policy enforcement but it makes total sense.

With all that in mind, a storage limitation policy might choose to purge events with the least recently accessed as their policy, but for such cases I think that it would be simple to say "tombstones are the last of the LRU that you should delete in such cases".