# Unreliable timestamps prompt

Farcaster is a distributed network made of operation-based CRDTs. Unlike other CRDTs, the hosts of the network are potentially adversarial, which introduces some challenges. One challenge is that timestamps are not necessarily true representations of when operations happened—how do we differentiate between an old operation that is only now reaching our hub vs a new operation with a fake timestamp?

One design decision we've had to make due to the unreliability of timestamps is signer revocation. When a signer is removed, we delete all operations ever signed by that key pair, rather than just preventing new operations.

### Example

A user, Alice, has authorized two signers for her account, A and B. She's posted casts from both signers.


Let's assume signer B is compromised, and Alice wants to revoke access for that signer. But she wants to keep the first two messages from that signer and revoke only the most recent one. This is her desired behavior:


The problem with this approach is that Signer B can still create messages with timestamps prior to 5 and merge them because timestamps can be manipulated. The final message could be re-created by Signer B with timestamp 1 and would be considered valid.

So our solution thus far has been to delete all messages from a removed signer and encourage users to re-sign messages that they want to keep with a different signer. Here's what that looks like:


This isn't a terrible solution, but the UX is weird, and it results in considerable network thrash where a bunch of operations are deleted and then quickly re-added with different signers.

### Other ideas?

Are there other ideas for proving timestamps of operations while preserving the concurrency attributes of CRDTs? We've thought about creating a snapshot of state on some regular cadence and preserving that on Ethereum, but I imagine there are other ideas we can pull from existing distributed systems to solve this problem more elegantly.