Martin Kleppmann

Solving that problem then mean in a decentralized setting where we don't have just a single server that can make that decision.

In a centralized setting, you know, you just have one server.

It decides,

Did the edit to the document come first or did the revocation come first?

And that one server makes that decision.

But if you have multiple servers, they might make different decisions.

So then you could have a consensus protocol, but then consensus is messy because it requires like some quorum votes and requires notes to be online.

And so we've been trying to do the whole thing without doing consensus.

But while preserving high availability, while preserving the ability for users to work offline, preserving the ability to...

synchronized peer-to-peer without any servers, for example.

That just makes the engineering challenge a lot harder.

And it's solvable, and we are close to solving it for AutoMerge, which is the CLDT library that I work on.

But it's just much less straightforward than it is in the centralized case.

But that's a nice example of where interesting engineering challenges arise from this desire to get away from centralized services.

And in this particular setting of a user getting their edit permissions revoked, if a revoked user still wants to, say, vandalize a document, they can just backdate their edit, give it an earlier timestamp.

So relying on clocks is absolutely useless here because people can forge the timestamps from those clocks and thereby then potentially undermine the access control mechanism.

So in this kind of system, we have to worry about potentially maliciously generated actions as well when the actions come from end user devices.

Exactly.

And that's what I mean with this long-term thinking.

This is an example of it where, because it's research, we can afford to take this idealistic principled stance.