Martin Kleppmann

But it also leads to this situation where the people have a gun against their head all of the time.

That isn't really a healthy situation to be in, in my opinion.

But changing that in such a way to take away that gun from customers' heads...

is difficult if you're in a business whose revenue depends on perpetuating that kind of lock-in situation and there i feel like in academia i have the freedom to work on things that go against this commercial incentive of companies and say like actually no i'm going to do what i think is right for the users and i'm going to say the commercial model of the companies making the software is second priority and i can afford to do that because i'm i'm not dependent on this commercial model

To add to this, it's very interesting and challenging engineering problems, right?

Yes, and it's wonderful to get to work on interesting engineering and computer science problems while at the same time trying to pursue this higher level vision.

Yeah, so with our vision of local first software, we are trying to get away from this dependency on centralized cloud services.

There may still be cloud services involved in syncing data between your phone and your laptop, say, because often going via cloud service is just the most convenient way of establishing that kind of communication.

But we just don't want to have to trust on a cloud service providing a particular function.

And if you can get away from assuming this one cloud service, you could, for example, have multiple cloud services on multiple cloud providers side by side, and you just sync by whichever happens to respond first or second.

sync with all of them and then if one of them disappears no problem because you've got the other one and so it gives us a huge amount of freedom and flexibility if we get away from this assumption of centralized cloud services but that introduces a whole bunch of interesting research and engineering challenges because so one thing that we've been working on lately say is access control you know simple problem you have a document you want to be able to grant collaborators access and you want to be able to revoke that access again

totally obvious, should be totally straightforward.

In a centralized cloud service model, it is totally straightforward.

Yeah, but if you want to run your system over multiple providers, or even in a peer-to-peer setting,

then, well, what could happen is that a user gets their edit permissions revoked, and concurrently, that user makes an edit to the document whose permissions have just changed.

And now some devices may see the edit to the document first and the revocation second, and so they would accept the edit to the document.

And another device may see it the other way around.

They may see the revocation first and then the edit to the document second, and they'll drop the edit to the document because they think it's not authorized.

And now those devices have become inconsistent with each other, permanently inconsistent.

So that means if we actually want to ensure consistency, even for this fairly basic setup, we now have to somehow figure out how to resolve the situation of an edit that is concurrent with the revocation of the user who made that edit.