Loro retweeted
We open-sourced Lody’s CLI and local desktop.
A shared workspace around the coding agents you already run. Sessions, diffs, and decisions stay with the team.
Built on @loro_dev. More of that syncing stack will be open too.
Lody is a shared workspace for the coding agents your team already uses.
The CLI and local desktop are now open source!
lody.ai/blog/lody-is-now-ope…
Loro retweeted
Iroh finally hit 1.0
If the P2P connection layer becomes reliable, a whole class of apps that used to be painful becomes much easier to build. This feels especially well-suited for personal software.
More personal software feels worth building now!
Dial Keys, not IPs. After 4 years and more than 65 versions, iroh 1.0 is here to give you the direct connections you deserve.
We can’t wait to see what you will build!
iroh.computer/blog/v1
Loro retweeted
Loro Mirror is released! It makes building a collaborative experience much easier. You declare a simple schema and keep using setState. Mirror syncs a typed, immutable view of your app state with CRDTs, so you avoid most of the diff/patch glue
![import { LoroDoc } from "loro-crdt"; import { schema, SyncDirection, Mirror } from "loro-mirror"; // 1) Declare state shape – a MovableList of todos with stable Container ID `$cid` type TodoStatus = "todo" | "inProgress" | "done"; const appSchema = schema({ todos: schema.LoroMovableList( schema.LoroMap({ text: schema.String(), status: schema.String<TodoStatus>(), }), // $cid is the container ID of LoroMap assigned by Loro (t) => t.$cid, ), }); // 2) Create a Loro document and a Mirror store const doc = new LoroDoc(); const store = new Mirror({ doc, schema: appSchema, // InitialState will not be written into LoroDoc initialState: { todos: [] }, }); // 3) Subscribe (optional) – know whether updates came from local or remote const unsubscribe = store.subscribe((state, { direction, tags }) => { if (direction === SyncDirection.FROM_LORO) { console.log("Remote update", { state, tags }); } else { console.log("Local update", { state, tags](https://pbs.twimg.com/media/G1c2oSSaAAE4jgO.jpg?name=orig)
ALT import { LoroDoc } from "loro-crdt"; import { schema, SyncDirection, Mirror } from "loro-mirror"; // 1) Declare state shape – a MovableList of todos with stable Container ID `$cid` type TodoStatus = "todo" | "inProgress" | "done"; const appSchema = schema({ todos: schema.LoroMovableList( schema.LoroMap({ text: schema.String(), status: schema.String<TodoStatus>(), }), // $cid is the container ID of LoroMap assigned by Loro (t) => t.$cid, ), }); // 2) Create a Loro document and a Mirror store const doc = new LoroDoc(); const store = new Mirror({ doc, schema: appSchema, // InitialState will not be written into LoroDoc initialState: { todos: [] }, }); // 3) Subscribe (optional) – know whether updates came from local or remote const unsubscribe = store.subscribe((state, { direction, tags }) => { if (direction === SyncDirection.FROM_LORO) { console.log("Remote update", { state, tags }); } else { console.log("Local update", { state, tags
Loro retweeted
The @loro_dev team is also very responsive. We don’t take adding dependencies lightly, but the library’s quality combined with its team gave us the confidence we needed to bet on them
if you are looking for a real-time collaboration library (based on CRDTs), I highly recommend @loro_dev. it's performant, type-safe, and actively maintained
and I've tried them all
Loro retweeted
The slides for the talk are available here: loro-slidev.vercel.app/
📣Reminder to tune in to #LoFi/21 this coming Tuesday at 8:00 AM PST (November 26) 👉🏽 lofi.so
We have yet another exciting lineup featuring Felicia Chang (@felchang), from @jamsockethq, Sahil Lalani (@SahilLalani0) from @surferprotocol and Zixuan Chen (@zx_loro) from @loro_dev
Loro retweeted
collaboration between biologists, data scientists and engineers on data visualization tasks create challenges in consistency
state is scattered across different laptops, network connections can drop and updates are unordered
we have been working with loro.dev to build programmable dashboards for scientific data using rich text CRDTs and provide real world tasks in biotech to improve the performance of their library
Loro retweeted
Eg-walker (Replayable Event Graph) paper is finally out! It hit the front page of Hacker News without surprise. Loro is built on top of this idea because I believe it will shatter how we build collaborative software in the future.
arxiv.org/abs/2409.14252
Loro retweeted
I added basic support for JSONPath. github.com/loro-dev/loro/pul…
Getting data out of LoroDoc now in Rust can be faster and easier.
JSONPath has a RFC now. I think it makes sense for us to support it 🤔 (as an optional feature)
en.wikipedia.org/wiki/JSONPa…
Loro retweeted
Soon you can trim redundant history in Loro CRDTs! It will minimize the overhead of CRDT metadata.
Usually, the cost of a CRDT doc increases with the history grows. There were tombstones that are hard to remove because the algorithm needs to use them to do the CRDT calculation.
Loro retweeted
🦜You can now use Swift to develop apps that require @loro_dev !
github.com/loro-dev/loro-swi…
Loro retweeted
Loro (@loro_dev) is what I always dreamed of for a CRDT:
✅ Great API, docs, performance, intent preservation, no interleaving, movable lists and trees.
🚀 Also planned state management libraries and devTools.
I am sure that this library is going to make history.
Loro retweeted
Using "index" to denote cursor positions can be unstable, as positions may shift with document edits. We can use characters' IDs to represent positions stably in a Text CRDT. What should we call them?
10%Relative positions
24%Stable positions
50%Cursors
16%🍿
50 votes • Final results Loro retweeted
We may also create a two-way door if the app allows applying the diff from exported local files. The conflicts between edits in the app and the edits on the local files can be merged automatically by CRDTs.
Exporting = one-way door
File over app = two-way door
Do not mistake the map for the territory.
Many apps allow you to export your data. That's better than nothing, but not the same as editing files directly. An export is a representation of your data. It's an output of the source. It's a one-way door.
The file over app philosophy does not make a distinction between data and file. Both are one and the same. The source is the output, and vice versa. It's a two-way door.
Exports are useful if you want to exit the tool. Exports are not useful if you want to directly manipulate your data. Exporting requires your explicit intention, whereas file over app requires no intention at all.
File over app means you have possession of your data, it can be directly read and edited with multiple different tools at any time.