deletions with long expiration tags would be a good approach, like a year or so, to save storage space since after a while users will stop trying to re-save deleted events.
Discussion
deletions should not have expiration tags
relays can set their own retention policy for deletions. also, a few KB of data is nothing.
any relay that implements expiration tags the users can set their targets as well, just sayin'
nothing you as administrator can do except make your relay ignore these tags, which is kinda shitty.
deletions cannot be deleted or expired
the spec says nothing about any events being excluded
NIP-40
======
Expiration Timestamp
--------------------
`draft` `optional`
The `expiration` tag enables users to specify a unix timestamp at which the message SHOULD be considered expired (by relays and clients) and SHOULD be deleted by relays.
#### Spec
```
tag: expiration
values:
- [UNIX timestamp in seconds]: required
```
#### Example
```json
{
"pubkey": "
"created_at": 1000000000,
"kind": 1,
"tags": [
["expiration", "1600000000"]
],
"content": "This message will expire at the specified timestamp and be deleted by relays.\n",
"id": "
}
```
Note: The timestamp should be in the same format as the created_at timestamp and should be interpreted as the time at which the message should be deleted by relays.
Client Behavior
---------------
Clients SHOULD use the `supported_nips` field to learn if a relay supports this NIP. Clients SHOULD NOT send expiration events to relays that do not support this NIP.
Clients SHOULD ignore events that have expired.
Relay Behavior
--------------
Relays MAY NOT delete expired messages immediately on expiration and MAY persist them indefinitely.
Relays SHOULD NOT send expired events to clients, even if they are stored.
Relays SHOULD drop any events that are published to them if they are expired.
An expiration timestamp does not affect storage of ephemeral events.
Suggested Use Cases
-------------------
* Temporary announcements - This tag can be used to make temporary announcements. For example, an event organizer could use this tag to post announcements about an upcoming event.
* Limited-time offers - This tag can be used by businesses to make limited-time offers that expire after a certain amount of time. For example, a business could use this tag to make a special offer that is only available for a limited time.
#### Warning
The events could be downloaded by third parties as they are publicly accessible all the time on the relays.
So don't consider expiring messages as a security feature for your conversations or other uses.
Publishing a deletion request event against a deletion request has no effect. Clients and relays are not obliged to support "unrequest deletion" functionality.
This would reasonably extend to expirations as well which are basically implicit deletions.
deleting deletes is not the same as expiring a delete.
it is not contrary to the spec for clients to send delete events with expirations in any way. you probably just were too caught up with your admin powah to realise that relays are not prohibited from deleting delete events on the basis of expiration. because they are. just like you as relay developer and administrator can override this.
come to think of it, i possibly haven't got an exception to allow administrators to delete delete events. since that's outside of spec and any prohibition of this is contrary to the sovereignty of teh node operator i should check that, making a mental note.
Amethyst (I don’t know if there are others) lets you remove likes and reposts but other clients are not consistent with how they display those undos. There’s no consistent experience and that’s got to be incredibly frustrating for most new users.