I built a background daemon in Rust that exposes CRDT documents over a Unix socket. Any local process (Rust, Python, Node, shell scripts) can share live, conflict‑free state with zero cloud.

One‑line pitch: It’s Redis, but every value is a CRDT document and it never leaves your machine.

The problem

CRDT libraries (Yjs, Automerge, Loro) give you merge math, but you still have to build transport, persistence, and IPC. Most sync tools assume cloud. I wanted the missing piece: a local IPC daemon that exposes CRDTs the way Redis exposes data structures.

60‑second try‑out (Linux)

# build + install
cargo build --release --workspace
sudo cp target/release/hexsync /usr/local/bin/hexsync
sudo cp target/release/hx /usr/local/bin/hx

# run daemon
RUST_LOG=hexsync=info hexsync

In another terminal:

hx set work project "hexsync"
hx set work mood "shipping"
hx watch work

Windows note: use WSL for now; native Windows support is planned.

Stack

• Tokio — async runtime, one task per client
• Loro — pure‑Rust CRDT engine
• Bincode — length‑prefixed binary protocol over Unix sockets
• Custom WAL — append‑only log, replay on boot

Tests

What’s next

Phase 6: LAN peer sync — daemons discover each other via mDNS and exchange Loro bytes over TCP. The network layer is just transport; merge logic stays inside Loro.

GitHub: https://github.com/Andrew-velox/hexsync

Feedback welcome, especially on the protocol and whether bincode is a good choice over MessagePack.

1 post - 1 participant

Read full topic