NIP-81 - Event Copy

[arthurfranca]

Please check the NIP for some use cases.

[fiatjaf]

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

[arthurfranca]

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)

[arthurfranca]

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]

Why?

[arthurfranca]

Example: if I'm copying an event that already has one P tag that also is a pubkey value, although with a custom meaning specific to that event kind, i end up with:

{
  // other fields
  "kind": 1006,
  "tags": [
    // other tags,
    ["P", "pubkeyA"], // copied from original event's "pubkey" field
    ["P", "pubkeyX"]  // copied from original event's one-letter tags
  ]
}

Now if I were to request one of the copies I made, and wanted a copy that had originally the pubkey field value "pubkeyX", I do ["REQ", "xyz", "{ \"kind\": 1006, \"#P\": [ \"pubkeyX\"], \"K\": .... }]. This will wrongly bring me the above event.

That's why ideally we consider I, P and K in events other than copies invalid. Don't copy these invalid events and you will not have to filter things out client-side.

For the same reason I didn't make it a parameterized replaceable event (the original could alread have a "d" tag and its worse cause maybe only the first d tag is indexed on some relay implementations, cause of what is written on NIP-33)

This is similar to the problem NIP-10 introduced. Can't request direct descendants of a specific root event without filtering out a bunch of events I don't want just because although the e tag means event id, it is used with different contexts ("root", "reply" and the legacy "mention").

[Semisol]

• Re-publishing using own quota: Use NIP-42 AUTH
• Group moderation: make a special kind to hide certain messaes
• 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. Or make a special kind to hide DM messages.

There is no use case imo.

[arthurfranca]

@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.

[arthurfranca]

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