Shared something very similar on HN a few years ago. The entire source code is about a hundred lines, which makes it easier for folks to review and trust: https://news.ycombinator.com/item?id=34083366
I had the foolish idea of installing a Tesla charger at home to charge my Bolt. I’ve been unable to ever use it.
The wall charger works fine with Teslas.
My car and adapter charge fine at Tesla superchargers.
But the home Tesla charger refuses to charge my Bolt.
(Yes I disabled vehicle restrictions and tried all sorts of combinations of settings for weeks before giving up. Tesla support was useless of course)
My anecdotal evidence confirms this. Friends in my home country are hooked on Telegram meme groups and as a result they’re spreading [Russian propaganda] conspiracy theories at alarming levels.
(Russia is really good at weaponizing memes but I don’t meant to single it out, the US has also been very successfully influencing the same country for decades via Hollywood movies for example)
When programmers think of locks, they think of something that can be used to guarantee mutual exclusion.
Distributed locks have edge cases where mutual exclusion is violated.
Implementation does not matter.
e.g. imagine someone shows you a design for a perpetual motion machine. You don't need to know the details to know it doesn't work! It would violate the laws of physics!
Similarly, anyone telling you they created an implementation of a distributed lock that is safe, is claiming their system breaks the laws of information theory.
"Distributed locks" are at best contention-reduction mechanisms. i.e. they can keep multiple processes from piling up and slowing each other down.
[Some] Paxos for example use leader election to streamline the protocol and achieve high throughput.
But Paxos safety does NOT depend on it. If there are multiple leaders active (which will inevitably happen), the protocol still guarantees its safety properties.
> They both reduce to a paxos style atomic broadcast
Atomic Broadcast guarantees order of delivery.
It does not (cannot) guarantee timing of delivery.
Which is what people want and expect when using distributed lock / leader election.
I'm sorry, I didn't mean to be bashful. I am not familiar with S3 and maybe what you describe is a perfectly safe solution for S3 and certain classes of usage.
I could not get past the point where you promulgate the idea that ZK can be used to implement locks.
Traditionally a 'lock' guarantees mutual exclusion between threads or processes.
"Distributed locks" are not locks at all.
They look the same from API perspective, but they have much weaker properties. They cannot be used to guarantee mutual exclusion.
I think any mention of distributed locks / leader election should come with a giant warning: THESE LOCKS ARE NOT AS STRONG AS THE ONES YOU ARE USED TO.
Skipping this warning is doing a disservice to your readers.
Atomic Broadcast (via Paxos or RAFT) does not depend on partial synchrony assumptions to maintain its safety properties.
Your internet or intranet networks are definitely asynchronous and assuming delays are bound is a recipe for building crappy systems that will inevitably fail on you in hard to debug ways.
"Distributed locks" are at best a contention-reduction mechanism. They cannot be used to implement mutual exclusion that is _guaranteed_ to work.
I've seen way too many systems where people assume TCP == perfectly reliable and distributed locks == mutual exclusion. Which of course it's not the case.
Telling people "here's a recipe to do locks" should come with a giant flashing sign that say: "this is not an actual lock (as in in-process locks) -- locks in distributed systems are impossible, this cannot be used as a recipe for mutual exclusion"
Here’s something similar-ish but using symmetric encryption (i.e. password):
https://mprimi.github.io/portable-secret/
https://news.ycombinator.com/item?id=34083366