An interesting question, related to the topic of non-repudiation. In this case, the thing Bob wants to do is repudiate having ever received the message. Here's one way to build a system which is secure against that:
All members of the P2P network have a public/private key pair (this is useful for lots of other things too, like end-to-end encryption). For the purposes of this question, we'll assume that the public keys of Alice and Bob are known both to each other and to the boss.
To ensure non-repudiation of messages both sent and received, the P2P software/protocol is such that:
- When a message is sent, the sender uses their private key to create a signature of the message, the timestamp, and a sequence number (unique identifier). These values and the resulting signature are transmitted along with the message itself. Now, the recipient can always prove that the sender sent the message and can't fake when it was sent.
- When a message is received, the recipient signs the message (including the sender's signature, timestamp, sequence number, etc.) with their receipt timestamp, using their (recipient's) private key, and sends that signature back to the sender. Until the sender receives (and verifies) this countersignature from the recipient, the message is considered undelivered; the sender can see an indication of message state. Thus, if the sender ever sees that the message is delivered, they can prove that it showed up on the recipient's chat client, and when.
- Both signatures and all their metadata, on every message, are stored in both clients.
Now, given these properties, let's look at how we might try to attack the system:
- Alice uses a modified client that will sign a message and display it as being sent with the desired timestamp, even if no such message was sent. There's no way to prove that it wasn't sent at that time, either. However, because the message doesn't have a valid recipient signature, it'll be clear that the message wasn't ever received, and if Alice wasn't lying, she should have noticed that the message wasn't received and done something about that.
- Bob uses a modified client that will let him see incoming messages without acknowledging receipt of them yet. Bob uses this to have messages that he wants to pretend he never saw just "silently fail" without ever sending the countersignature. However, in this case Alice will see that Bob's client "never received" the message, and will try to reach him some other way.
- Bob uses a modified client that will make it look like the message arrived too late for him to act on it, by altering the timestamp. However, Alice has the original message receipt (countersignature), which has the timestamp of when the message was received. She (or her client) should notice if the receipt date is in the future. If it's not - that is, if Bob's copy is modified after the receipt is sent - then Alice still has a copy of the original receipt, with the original timestamp, signed with Bob's private key.
- Alice, trying to make Bob look bad, crafts a fake message (that looks like it was sent but wasn't actually), and uses a modified client that displays the message as having been received. However, Alice doesn't have Bob's private key, so Alice's client can't produce a valid countersignature from Bob. When the boss looks at the messages that Alice supposedly sent, and tries to verify the supposed countersignature on Alice's message using Bob's public key, it will be revealed to be invalid.
Obviously, part of this system depends on people making sure that their messages are received. It's impossible to prove, for a message for which you have no countersignature, whether or not the recipient ever got it. So long as you get a countersignature, though, and the timestamp makes sense, either party can now prove that the message was exchanged, and when. Neither side can delete all proof of the exchange, or modify any detail, unilaterally; they would need to cooperate to fake anything.
