I think if you want to save it you should just save it.

let me try to make things clearer...
edit: below example is easier to grasp

clients willing to support any of the listed examples should request both the regular kind events and the copies of same K tag (e.g. when fetching a feed).
1 the relay event republishing case is considering relays that won't let you republish events that aren't yours (e.g. if you want to republish a thread).
2 the DM inbox example shows a solution that proves the received message is authentic while letting the receiver client control it (cause relay otherwise wouldn't let if user is not the author of the message).
3 group (i meant "channel") moderation is also imagining a solution that involves the chat client loading a channel's messages along with admin copies (the copies would be the moderated ones, and have preference over regular ones when original id == copy I-tag)

The Direct Message (kind 4) example:

User S (sender) sends a message m to user R (receiver).

R's inbox (received messages page) shows message m. However, R is unable to delete m from relay, cause he isn't its author (S is the author). In other words, R doesn't control his own inbox.

So this NIP proposes that R's client should generate an m copy (mC) whose author is the receiver R instead of the sender S.

• At the moment, m is considered unread.

• R's client can mark the message as read by just having an mC with its .content being the stringified m. (The "read at" date is the "copied_at" tag)

• Now S can delete his sent message m but it won't affect R's inbox, cause mC is there. And @fiatjaf it isn't a simple copy that lives at the clien'ts local database, its a copy the receiver owns (in that relays will consider the receiver as the author) that is automatically synced by leveraging relay database, i.e., no matter what client I'm using, it will be there

• Then R can delete the message from his inbox: delete mc and replace it by mC2 with empty .content (we don't just delete mc, cause without an mC/ mc2, it would seem as R havent read m yet)

@Semisol I will focus on the DM example cause it is a stronger selling point.

DM inbox: You can always make a deletion event that deletes others' DM messages from your own pubkey, and your client can then honor that. [...]

What you suggest will only work in one client, you are just cleaning a DM from the local client database. If I were to open my inbox on client no.2, all messages will be there.

What I propose is an inbox be made of event copies. An event copy proves that your client didn't create a fake message. It has the same queryiable fields of the original. It represents a read message. Or can later be deleted and then replaced by a version with no .content to represent a deleted message. Also, if the sender deletes the message from the relay after you've "read it" (after your client created a copy on the relay, not on local DB), it won't touch your inbox.

[...] Or make a special kind to hide DM messages.

Well this is what I just did. But it needs to have all the other technical features I listed.

I'm closing it as this event is too generic and the Inbox interop use case got no interest so probably gonna use NIP-78