FeatureRequest: message with last message hash to form a message list for no denying

[xialvjun]

Let's imagine such a scenario:

X: A is the No 1.
Y: Oh, got it. A is the No 1.
...
Years Passed
...
X: B is the No 1.
Y: But you said 'A is the No 1'.
X: I didn't say it.
Y: You said it. I have the message json which is signed by your pubkey.
X: OK, I said it. But I said 'Oh, sorry, I'm wrong, A is not No 1' quickly after I said 'A is No 1'. It's you not link to the relay server.
Y: ...

In fact, X is a liar. Is there a method to prevent X from lying?

I thought a method is every message has a field its last message's hash.

[vitorpamplona]

Is there a method to prevent X from lying?

No. Everybody can sign whatever they want and then sign a new message saying otherwise.

It could have been a lie, it could have been a mistake, it could have been a hacker.

In the end, you can never be certain that a signed package was correct. If the holder of the key says the key leaked and this is not him/her, there is no way to verify if that signature comes from the real user or the attacker.

In the same way, there is no way to verify if the author was trying to intentionally lie or if it was just a mistake.

The only thing you can track is the history of signatures and store them locally.

[xialvjun]

“The only thing you can track is the history”.

Yeah, history. But those liars try to change the history, try to change people's memory. So we need a method prevent them.

So make a field msg.last_msg_hash:

function create_msg(user, txt) {
  return { content: txt, hash: sha256(txt + user.id + Date.now()), user_id: user.id, last_msg_hash: user.msg_list.at(-1).hash };
}

With last_msg_hash, subscribers can form a ordered msg list from the author, and the msg lsit order is creditable since it's one by one like blockchain.

As to Key Leaked, if the key thief said something you don't want to say with your key, and with field last_msg_hash, you should find it right at you publishing your second note.

[vitorpamplona]

That's kind of what we already do with replies (NIP-10). You just add a p-tag with the previous event ID

[xialvjun]

Nevermind. I realized that my previous ideas were too mechanical and inflexible. In most cases, time ordered msg list is enough.

If someone wants to show that he is trustworthy, he should ask several major relay servers for message reception confirmation message.