Feature: auto-delete

[nostr-protocol]

Feature: auto-delete

[scsibug]

I was originally in favor of a top-level "expires_at" field, similar to "created_at". I think it is different enough from NIP-09 that it should be a distinct proposal though (NIP-09 deals with deleting already-published events).

Counter-arguments for an expiration field:

• Relays are already going to decide on their own expiration policy that probably have them ignoring an expires_at field, especially if those tend to be long.
• Event kinds may end up having community de-facto defaults on expiration. Example: encrypted direct messages may drop off all relays after ~3 months, clients would be expected to pick up their messages before that time. Delete messages may be handled immediately, and then dropped after a few weeks. Old contact/follow lists are already dropped after a new one is published. Metadata is dropped upon a new event.

Arguments for a dedicated field:

• Allows relays to get rid of events at a time the client is most happy with.
• Supports more advanced use cases where relays may charge users for a total number of non-expired events, so this (+ NIP-09) gives clients a mechanism to communicate with relays to manage the storage space allocated to them.

My personal feeling is - events, in general, won't live forever anyways. "Expiration" is a neat hint to bundle, but there are already a number of ways that events will drop off the network. If someone really wants to get rid of something they can use NIP-09. Otherwise, relays and clients/consumers can determine their own policies for retention, and since they are paying for the storage, their preferences should dominate. I think this gives an illusion of control to clients/publishers that they don't really have, and should not expect.

[jg1uaa]

How about to add "until" and "since" field to event itself? is it difficult?