Looks nice but not open source

We chose to adopt the Elastic License 2 primarily because of the significant investment we've made in developing this technology, including a robust cross-platform network layer that enables users to implement offline-first functionality with just two lines of code. This license also helps protect our work from being forked and commercially exploited by larger tech companies.

Looks really cool! Congrats on the launch

̶L̶o̶o̶k̶s̶ ̶l̶i̶k̶e̶ ̶y̶o̶u̶’̶r̶e̶ ̶i̶n̶f̶r̶i̶n̶g̶i̶n̶g̶ ̶o̶n̶ ̶t̶h̶e̶ ̶S̶Q̶L̶i̶t̶e̶ ̶a̶u̶t̶h̶o̶r̶’̶s̶ ̶t̶r̶a̶d̶e̶m̶a̶r̶k̶.̶

Edit: Thanks for clarifying that. It'd be great if you can add it to your README, because the name looks very suspicious at first glance. If you have the rights to use it, explicitly mention it.

Very cool, I'm working on something similar!

Naturally I have some questions:

1. I don't see any examples for foreign key constraints (ON DELETE and ON UPDATE) or UNIQUE constraints. Are constraints still supported? 2. How is row-level privacy implemented? Are "forbidden" rows not synced by the server logic, or are they encrypted?

Does this have any relation to: https://github.com/vlcn-io/cr-sqlite ?

Some of the API naming is similar (db_version, site_id, seq, commit_alter, etc), although the project source is very different (C rather than Rust, different feature set).

crsqlite is no longer maintained so I might be interested in migrating.

Looks like the "embedded networking" and therefore all network-related syncing is tightly coupled to the closed SaaS running at https://sqlitecloud.io.

It would be cool if the server-side sync API was also documented and versioned, which would allow the possibility of independent compatible self-hostable backend implementations to offset the vendor-lock-in concern.