[MarquesMa]

I'm very intrigued for the CRDT approach. I always want to try CRDT but always end up giving up local-first for simpler approaches, because I can't convince myself fully since there's a risk of accumulating CRDTs data structures too large.

Really looking forward to see your success, it might move the industry forward and bring better apps for the users.

BTW the app is fantastic!

[adamwiggins]

Thanks! Yes, CRDTs are risky in the sense that they are computer science that is only just at the edge of what's possible in software today. A few folks have put them into practice in small ways (Figma comes to mind) but I wouldn't recommend it for most software projects.

That said I hope we (meaning everyone working on CRDTs and local-first) can help make it suitable for production use and perhaps it will be a common, maybe even standard, way to build software five or ten years from now. That's my hope/dream, at least.

[jka]

Do you have any plans to handle schema changes for the content stored within the CRDTs as the clients evolve?

(I've been puzzling over that question during some local-first dabbling; I have a feeling that lenses[1] -- or something like them -- may provide a route towards schema version upgrades without any peer synchronization guarantees)

[1] - https://www.cis.upenn.edu/~bcpierce/papers/lenses-etapsslide...

[mmcgrana]

Yep, we already have basic support for versioning.

The foundation of our approach is to have a versioned, documented schema shared among clients. Every write down to the individual attribute level is persisted with a schema version. We're already several versions in, and indeed think it's healthy to get experience with version updates frequently so that it's not an unusual occurrence.

Currently we use this schema to interpret / coerce values as needed at read-time. For example we see an attribute has schema version 1, and know that it should be interpreted in the sense that we meant as of version 1. In the future, we may also choose to write out updates for "migrations" where that'd be helpful. So that e.g. instead of having to re-interpret values for older version 1, we'd right out an update to he attribute that overwrites the old value and updates the version tag to e.g. 3.

We do think lenses are interesting and the lab from which we spun out has done some good work with them: https://www.inkandswitch.com/cambria/. They're just a bit complex for our modest needs re: schema versioning at this time.

[jka]

Nice - perhaps there's some kind of equivalence (or at least similarity) between lenses and those migrations. Thanks for the response!

[jka]

Eh.. probably because I learned of lenses from Ink & Switch in the first place: https://www.inkandswitch.com/cambria/