Hey HN, I built SyncKit after shipping two local-first projects (RestBolt and Graft) and realizing there's no simple way to add cross-device sync.
The problem: Existing solutions are either too complex (Automerge/Yjs require learning CRDTs) or too restrictive (Firebase isn't truly local-first, Supabase has no offline support - issue #357 has been open 4+ years with 350+ upvotes).
SyncKit is the middle ground: simple API, works offline-first, self-hostable.
Technical highlights:
- TLA+ formal verification: 118,711 states checked, caught bugs before implementation
- Rust → WASM core (48.9KB gzipped)
- 700+ tests including 80 chaos tests (zero data loss)
- Server: Bun/Hono WebSocket (SDK works in any JS runtime)
- Production-ready: v0.1.0 on npm and Docker Hub
Known limitations (v0.1.0):
- LWW only - advanced CRDTs (Text, Counter, Set) coming in v0.2.0
- React hooks only - Vue/Svelte adapters planned
- Reference server is Bun (Node/Deno coming v0.3.0)
Happy to answer questions about the CRDT implementation, TLA+ modeling, or WebSocket architecture.
I've built my own sync engine in rust to run against supabase. It doesn't run the browser though, it's for a native app (tauri in my case). It's column level lww.
I have one place where I'm thinking I might need a crdt due to the complexity of the data and how you collaborate with it.
People take my app offline for long periods of time then reconnect with 1000s of records to sync so my sync is backgrounded and built to deal with several mb of data in sqlite files.
Anyway I'm interested in taking a further look at your thing over the holidays to see if it's worth switching or making partial use of it.
Not yet, but it's definitely something I'm considering.
Right now v0.1.0 is React (web) only. I'm planning Vue/Svelte for v0.2.0, and React Native could absolutely be v0.3.0 or sooner if there's demand.
The nice thing is the core sync engine is Rust → WASM, so it's framework-agnostic. The main work is just creating the React Native bindings and not rebuilding the sync logic.
Are you working on something with React Native? Curious what your offline sync needs are because it'd help me prioritize what to build next.
This is impressive!
After Realm depreciation I have been trying many different offline sync options, they are especially few on Dart…
Dart-Rust binding generator is pretty great though so it’s nice this is in Rust. Will keep an eye on this.
But I’m a little confused about why it says “Zero data loss with automatic conflict resolution” on the top level page and “data loss possible” under the disadvantages of last-write-wins conflict resolution. It makes sense that you have to start somewhere, but to my mind, last-write-wins isn’t really conflict resolution? What does using this library solve?
I guess it means edits to different fields don’t conflict. But if it’s the same field, it will get clobbered.
Based on the commits(especially the early/foundational ones) this seems to be built primarily with Claude, but I don't see that mentioned in the README.
I don't want to take away from the work you've done, as you're clearly knowledgeable, but as someone else observed, heavy use of AI assistance can be observed in all your public projects. It's worth explicitly addressing, especially considering the foundational nature of your project: it's not easily replaced if it turns out to have to have subtle bugs.
Though I rarely use it myself, I'd like to know, simply because I'm curious as to how other engineers have incorporated such assistance it into their process.
I think I know what this is, but the description is so much in its own context I'm not sure. It's for web-apps that also want an offline local version that works and deals with syncing the data when online again and either local or remote is updated?
It probably markets and explains itself perfectly find for someone in that space and/or looking for this solution, so I'm not sure that's actually a problem, but if you also want to stick in the mind of someone that sees this and doesn't have any current interest, but may stumble into needing a solution like this in the future, a few extra words in your initial description might help it be understood more quickly and be something remembered even if they don't dive into it. Or maybe it's fine and I'm just a bit slow today.
I want to create a local first, offline/p2p realtime multiplayer prototype app soon with reactive/signal data model and frontend agnostic design (considering solidjs/svelte). I'm on a tech research stage. How does it compare to rxdb, tinybase and zero sync? For reference right now I'm considering tinydb/rxdb.
Some time ago I was looking for a similar solution –offline first and easy sync– and was happy to find https://jazz.tools/. There are many things in common between these two projects. Just mentioning in case you want to check it out.
Interesting/impressive project, and would be doubly interested in the workflow used to develop it. Could stand to have more human-voiced docs though. Aside from all the usual reasons I'd avoid using a <1mo dependency over something like Yjs, the bog-standard claude copy on differentiators/reasons to migrate is fairly off-putting to me.
Also maybe bias, but there are still ennough obvious agent artifacts/byproducts in the code base that it makes me doubt that the details were thoroughly attended to, and that's where the devils are.
22 comments
[ 3.1 ms ] story [ 41.8 ms ] threadThe problem: Existing solutions are either too complex (Automerge/Yjs require learning CRDTs) or too restrictive (Firebase isn't truly local-first, Supabase has no offline support - issue #357 has been open 4+ years with 350+ upvotes).
SyncKit is the middle ground: simple API, works offline-first, self-hostable.
Technical highlights: - TLA+ formal verification: 118,711 states checked, caught bugs before implementation - Rust → WASM core (48.9KB gzipped) - 700+ tests including 80 chaos tests (zero data loss) - Server: Bun/Hono WebSocket (SDK works in any JS runtime) - Production-ready: v0.1.0 on npm and Docker Hub
Known limitations (v0.1.0): - LWW only - advanced CRDTs (Text, Counter, Set) coming in v0.2.0 - React hooks only - Vue/Svelte adapters planned - Reference server is Bun (Node/Deno coming v0.3.0)
Happy to answer questions about the CRDT implementation, TLA+ modeling, or WebSocket architecture.
GitHub: https://github.com/Dancode-188/synckit npm: @synckit-js/sdk
I've been using Automerge for a while and haven't had to look at any CRDTs. To me this looks very similar to Automerge.
Neat project!
I have one place where I'm thinking I might need a crdt due to the complexity of the data and how you collaborate with it.
People take my app offline for long periods of time then reconnect with 1000s of records to sync so my sync is backgrounded and built to deal with several mb of data in sqlite files.
Anyway I'm interested in taking a further look at your thing over the holidays to see if it's worth switching or making partial use of it.
Right now v0.1.0 is React (web) only. I'm planning Vue/Svelte for v0.2.0, and React Native could absolutely be v0.3.0 or sooner if there's demand.
The nice thing is the core sync engine is Rust → WASM, so it's framework-agnostic. The main work is just creating the React Native bindings and not rebuilding the sync logic.
Are you working on something with React Native? Curious what your offline sync needs are because it'd help me prioritize what to build next.
https://github.com/Dancode-188/synckit/blob/main/docs/guides...
But I’m a little confused about why it says “Zero data loss with automatic conflict resolution” on the top level page and “data loss possible” under the disadvantages of last-write-wins conflict resolution. It makes sense that you have to start somewhere, but to my mind, last-write-wins isn’t really conflict resolution? What does using this library solve?
I guess it means edits to different fields don’t conflict. But if it’s the same field, it will get clobbered.
https://github.com/orbitinghail/graft
However, they're clearly two different projects.
I don't want to take away from the work you've done, as you're clearly knowledgeable, but as someone else observed, heavy use of AI assistance can be observed in all your public projects. It's worth explicitly addressing, especially considering the foundational nature of your project: it's not easily replaced if it turns out to have to have subtle bugs.
Though I rarely use it myself, I'd like to know, simply because I'm curious as to how other engineers have incorporated such assistance it into their process.
It probably markets and explains itself perfectly find for someone in that space and/or looking for this solution, so I'm not sure that's actually a problem, but if you also want to stick in the mind of someone that sees this and doesn't have any current interest, but may stumble into needing a solution like this in the future, a few extra words in your initial description might help it be understood more quickly and be something remembered even if they don't dive into it. Or maybe it's fine and I'm just a bit slow today.
Also maybe bias, but there are still ennough obvious agent artifacts/byproducts in the code base that it makes me doubt that the details were thoroughly attended to, and that's where the devils are.