FilterHN

Show HN: SyncKit – Offline-first sync engine (Rust/WASM and TypeScript)

30 points

by danbitengo

3 hours ago

| past

| 5 comments

| github.com

| HN

▲

p2hari

6 minutes ago

[-]

Always nice to see something in here. Would love to hear what is your take on https://www.instantdb.com/?

▲

gagik_co

34 minutes ago

[-]

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.

▲

danbitengo

19 minutes ago

[-]

Thanks! Yeah, Realm's shift in direction left a gap in the offline-first space.

I didn't build Dart bindings yet (Rust → WASM → TypeScript for v0.1.0), but since the core is in Rust, Dart bindings via dart_rust_bridge are definitely feasible. Would actually be a great addition.

Are you actively looking for a Realm replacement for a Dart project? Curious what your offline sync requirements are. It might help me prioritize Dart support

▲

satvikpendem

2 minutes ago

[-]

I use Loro CRDT, which is written in Rust as well, on my Dart apps with flutter_rust_bridge and it works pretty well. For syncing I'm using their Loro protocol product although I used iroh before. However, the annoying thing about how the CRDT libraries work is that they're essentially key value NoSQL type storage, not relational. I would love something like SQLite or Postgres on both the server and client that can sync, which companies like ElectricSQL have, but no Dart bindings and also I'd prefer to be in the all Rust ecosystem as well as self host.

▲

danbitengo

3 hours ago

[-]

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.

GitHub: https://github.com/Dancode-188/synckit npm: @synckit-js/sdk

▲

threatofrain

54 minutes ago

[-]

TLA+ checked! Whoa!

▲

danbitengo

16 minutes ago

[-]

Thanks! The TLA+ modeling actually caught 3 bugs even before I wrote any code. Worth the upfront investment. It's way easier to debug a state machine model than distributed sync logic.

Happy to share more about the verification approach if you're interested!

▲

mike_kamau

26 minutes ago

[-]

Good work @danbitengo Is this usable in native Android app development?

▲

danbitengo

9 minutes ago

[-]

Thanks! For native Android, not directly yet because v0.1.0 is Rust → WASM → TypeScript (web/Node/Deno/Bun).

But since the core sync engine is pure Rust, native Android bindings are definitely possible. The main paths would be:

1. JNI bindings directly from Rust

2. Or using the existing WASM core with a JVM WASM runtime

Haven't prioritized this yet since v0.1.0 focused on web/JS ecosystem, but if there's demand for Android, I could explore it. Are you working on something that needs offline sync on Android?

▲

android521

2 hours ago

[-]

Is support for react native on the roadmap?

▲

danbitengo

1 hour ago

[-]

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.