I believe I saw your video presentations on YouTube [0] from the Local First Discord server [1], so nice to see your Show HN here. I am not using TypeScript so I might not be your target audience, I'm using local-first especially for mobile apps where connections can be spotty unlike the web which by definition (at least on first load) is always connected to the internet, and I'm using Flutter for this use case, as well as a backend in Rust. Other local first solutions are generally agnostic to the client and server because they work directly on the database layer, ie ElectricSQL and PowerSync will sync the client and server database. Other solutions with CRDTs can also work on the client and server with some FFI, ie automerge is in Rust so in my case it'll work via FFI on the Flutter side via flutter_rust_bridge (or WASM on the web) and of course on my Rust backend server, but it looks like you are looking to offer a more classic client-server syncing solution instead needing conflict free resolutions on disparate clients, ie the server is the source of truth.

So with all that, my question is, is there a reason you guys went with more of a full language level solution rather than being more agnostic to the client and server? It seems harder to support other languages and frameworks other than JS based ones in the future, but I suppose the market for that is already big enough. ElectricSQL etc also have SDKs for TypeScript as well as Flutter and others so they are similar to your solution but it seems like they can support more clients and servers in the future just by building SDKs for them.

Another question, looks like you eventually want to compete with Supabase but they are already experimenting with database level syncing and CRDTs in Postgres [2] and might catch up with your solution, any thoughts on that?

[0] https://www.youtube.com/playlist?list=PLTbD2QA-VMnXFsLbuPGz1...

[1] https://localfirstweb.dev/

[2] https://news.ycombinator.com/item?id=33931971