czx111331
Joined 7 years ago
Karma
463
Submissions
45
Member since
Sep 6
Twitter: https://twitter.com/zx_loro
mastodon: https://hachyderm.io/@zx
View on Hacker NewsRecent submissions
Comment · 1 year ago
Perhaps the most important difference is that software — even after being purchased and used — remains relatively easy to patch, unlike a physical lock.
Comment · 1 year ago
loro-prosemirror[1] offers much better support for integrating Loro with ProseMirror/Tiptap.
In theory, loro-mirror could also be used to integrate Loro with other rich-text editors, but that wasn’t its original design goal and it may need further refinement to work well.
Comment · 1 year ago
I believe that in the right contexts—specifically where eventual consistency is acceptable—the local-first paradigm is highly valuable and will gradually become mainstream. A major factor limiting adoption today is that existing local-first solutions are incomplete: when building such applications, developers must handle many problems that are trivial under strong-consistency or traditional models. This raises the learning cost and creates significant friction for paradigm shifts.
Our recent work on Loro CRDTs aims to bridge this gap by combining them with common UI state patterns. In React, developers can keep using `setState` as usual, while we automatically compute diffs and apply them to CRDTs; updates from CRDTs are then incrementally synced back into UI state [1]. This lets developers follow their existing habits without worrying about consistency between UI state and CRDT state. Paired with the synchronization protocol and hosted sync service, collaboration can feel as smooth as working with a purely local app. We’ve built a simple, account-free collaborative example app[2]. It only has a small amount of code related to synchronization; the rest looks almost the same as a purely local React app.
Comment · 2 years ago
Is Bitcoin a "public sync" application by the definition?