00:42:35  * phatedquit (Remote host closed the connection)
01:44:00  * phatedjoined
01:48:27  * phatedquit (Ping timeout: 240 seconds)
02:10:23  * Inviz_joined
02:10:51  <Inviz_>Hello! A theoretical question: Is operational transformation algorithm enough to build a reliable p2p sync system? Are there theoretical limits to what it can do? Why is OT not popular in distributed data systems, and instead they rely on consensus? I developed an OT library for arbitary JSON myself, and I just want to understand if I'm missing something. I think it's the best thing ever. But not many people do it?
03:32:23  * phatedjoined
03:36:51  * phatedquit (Ping timeout: 258 seconds)
04:07:12  * pfallenopquit (Ping timeout: 260 seconds)
04:34:48  * Inviz_quit (Quit: Page closed)
04:35:32  * Inviz_joined
04:43:14  * phatedjoined
04:47:27  * phatedquit (Ping timeout: 240 seconds)
06:34:17  * pfallenopjoined
06:53:44  * pfallenopquit (Read error: Connection reset by peer)
06:53:54  * pfallenopjoined
10:26:07  * mylesborinsquit (Quit: farewell for now)
10:26:38  * mylesborinsjoined
13:05:02  * savantgardejoined
14:59:51  <toddself>Inviz_: i actually work on OT stuff for my day job
15:00:06  <toddself>The problem with OT is you need a central coordinating server
15:00:30  <toddself>something has to mark the change as "accepted" and then inform the rest of the clients that they should process it, and increase the revision count
15:01:03  <toddself>So it makes it super hard to do this p2p since you need a "leader"
15:01:11  <toddself>CRDTs don't have this issue (but have other issues)
15:01:26  <toddself>however, you should look at noffle's hyperpad which is REALLY cool
15:29:18  <noffle>o/
15:29:29  <noffle>AMA!
16:10:02  <jfhbrook>OT?
16:10:09  <jfhbrook>I know OTT
16:12:22  * savantgardequit (Remote host closed the connection)
16:12:49  * savantgardejoined
16:17:28  * savantgardequit (Ping timeout: 240 seconds)
19:17:22  * savantgardejoined
20:59:10  * phatedjoined
21:03:36  * phatedquit (Ping timeout: 260 seconds)
21:03:37  * phated_joined
21:34:07  * savantgardequit (Remote host closed the connection)
21:34:44  * savantgardejoined
21:39:10  * savantgardequit (Ping timeout: 246 seconds)
23:22:16  * phated_quit (Remote host closed the connection)
23:27:13  * phatedjoined
23:39:51  <Inviz_>toddself: thanks for reply. Can you please elaborate on why leader is actually needed, if all changes are guaranteed to converge, eventually? I understand that given that OT is not idempotent, I'd have to make sure everybody merges with each other only once. I also understand that it's useful to reset the operation log once in a while by releasing new "version" of data snapshot. However I do not see why leader is strictly necessary
23:42:45  <Inviz_>I see that having a central sync server is the easiest way to guarantee data consistency with OT and the least amount of surprise when merging lots of changesets. Though still, the order of operations don't matter if they converge. We don't strictly need to enforce it