The great thing here is that OT requires a central server for coordination, whereas CRDT's doesn't. Actors can be full P2P and network partitioned and still converge.
The definition you give for SEC seems to describe regular EC. SEC is stronger in the sense that it requires all nodes to end up in the same state as soon as they recieve the same updates, without the need of consensus or rollbacks.
Missing the part about operations/state updates being idempotent. Without idempotence, the communication model has to be exactly-once delivery rather than the more realistic asynchronous broadcast model. The data types demonstrated would not work in an asynchronous broadcast network where messages get duplicated without additional safety checks like storing the hash of each update previously applied.
Why do you need 2 counters to increment and decrement? Why not just keep one number and add and subtract to it; in the end, it should still have the same state, right?
CRDT are monotnic. values can either be greater or the same. but won't get smaller. let say one data has come as et: 2, and other one came as et: 3. We will be taking max of these two which is 3 because of the thing I mentioned previously. So how's decrement gonna work here as we are taking max and value has not been reduced in this example? for this reason we are having 2 separate counter for increment and decrement logic.
Can this principle be used as a consensus algorithm for a distributed ledger (especially for a cryptocurrencies)? Besides, what prevents the gurus from lying on their respective timestamp? For example guru 1 wants to impose his answer 'Family' he can put a bigger timestamp than guru 3. What's the advantage of keeping track of all the increments and all the decrements of an integer? What happens if 2 modifications happen with the same timestamp?
"What happens if 2 modifications happen with the same timestamp?" In SEC, we can initially agree how we resolve the conflict. For example, we have ToDo-list and 2 users (user_Id_0 and user_Id_1). When both two users renames one element of ToDo-list (in one timestamp), we have the conflict, and we can use our agree of resolving conflicts (for example, we can take renaming from user with Id 0, because he is older user than user with Id 1)
Subscribed within the first minute ! Great presentation
Thank you, I'm a frontend engineer about to implement a CRDT, this is truly helpful.
hilarious + super informative == genius!
Awesome explanation
Looking forward for the next video for dummies explaining "tons more"
Great video. Trying to move from OT to CRDT, this makes it a lot easier.
The great thing here is that OT requires a central server for coordination, whereas CRDT's doesn't. Actors can be full P2P and network partitioned and still converge.
What does OT stand for??? google aint helping
@@linkinl1 OT means Operational Transformation. Its an algorithm used in Google Docs. en.m.wikipedia.org/wiki/Operational_transformation
Great introduction!!! Thank you very much. Thumbs up!
please do more ! -- great explanation.
This is so well done. Cheers!
This is so great video! Thanks man!
The definition you give for SEC seems to describe regular EC. SEC is stronger in the sense that it requires all nodes to end up in the same state as soon as they recieve the same updates, without the need of consensus or rollbacks.
Awesome. Thanks for this video!
Very informative. Thanks a lot.
4:55 The very core of CRDT in three lines
Good stuff dude. Thanks!
that was great! well explained
and the gi joe example was creative and entertaining :D
Missing the part about operations/state updates being idempotent. Without idempotence, the communication model has to be exactly-once delivery rather than the more realistic asynchronous broadcast model. The data types demonstrated would not work in an asynchronous broadcast network where messages get duplicated without additional safety checks like storing the hash of each update previously applied.
great explanation, thanks very much
Also, can we not make division commutative, by forming it as a multiplication problem? a / b -> a * 1/b which is the same as 1/b * a
Great explanation! At 6:10 all of the actors should arrive at +8 and not +9 right?
+9 because all of them are SET ;)
Why do you need 2 counters to increment and decrement? Why not just keep one number and add and subtract to it; in the end, it should still have the same state, right?
I had the very same question. Love the presentation but this detail has me questioning my intuition.
@@louroboros search: An introduction to Conflict-Free Replicated Data Types (CRDTs) on youtube and go to timestamp 7:45
CRDT are monotnic. values can either be greater or the same. but won't get smaller. let say one data has come as et: 2, and other one came as et: 3. We will be taking max of these two which is 3 because of the thing I mentioned previously. So how's decrement gonna work here as we are taking max and value has not been reduced in this example? for this reason we are having 2 separate counter for increment and decrement logic.
Can this principle be used as a consensus algorithm for a distributed ledger (especially for a cryptocurrencies)?
Besides, what prevents the gurus from lying on their respective timestamp? For example guru 1 wants to impose his answer 'Family' he can put a bigger timestamp than guru 3.
What's the advantage of keeping track of all the increments and all the decrements of an integer?
What happens if 2 modifications happen with the same timestamp?
"What happens if 2 modifications happen with the same timestamp?" In SEC, we can initially agree how we resolve the conflict. For example, we have ToDo-list and 2 users (user_Id_0 and user_Id_1). When both two users renames one element of ToDo-list (in one timestamp), we have the conflict, and we can use our agree of resolving conflicts (for example, we can take renaming from user with Id 0, because he is older user than user with Id 1)
Does someone know how do we know the request is late comer or not?
Why does 'D' appear twice @11:50?
The versioning of set operations sounds like MVCC
MOAR LYK DIS
Nit: subtraction is not commutative. You can frame division to be commutative as well: a * (1/b) = (1/b) * a.
It is, it just cannot be mixed with addition in a single counter. A CRDT counter is two counters, one for increment and one for decrement.
great
Lmao, great explanation!
"FATHER JUST SAW 42 AND IGNORED THE REST"
5:05 😏