danbitengo

AI agents are taking real actions — deleting files, sending emails, merging code. When something goes wrong, the question is always: did a human actually authorize that, and can you prove it?

Oath is an open protocol for cryptographically signed human intent. Before an agent acts, it checks for an attestation:

oath attest --action "database:delete_records:project_alpha" \

        --context "cleanup approved"

oath verify --action "database:delete_records:project_alpha"

# → ATTESTED proof: a1b2c3d4

If there's no attestation, the action is blocked. The interesting part: the absence of a signature is itself evidence. An agent can't claim it was authorized if there's no cryptographic proof that it was.

Security model: the private key never leaves your machine. The agent only calls verify, never attest. Attest is a human command. As secure as SSH key storage - same threat model, no central authority to compromise.

The repo has a working demo - an agent running 5 actions, 2 attested, 3 blocked — and a protocol spec at v1.0.0 (CC0, public domain). Anyone can implement the protocol in any language.

What's not there yet: multi-device sync and a Python package. Would appreciate feedback on the protocol design, especially the action class format (namespace:action:scope) and whether the signing model covers edge cases I haven't thought of.

Try it now: https://localwrite-demo.fly.dev

Open in two tabs, join a room, start typing. That's the pitch.

SyncKit is an offline-first sync engine. Rust core compiled to WASM, TypeScript SDK, works in any framework.

What's new since v0.1.0 (which some of you saw here 75 days ago):

- Live demo (LocalWrite) - collaborative editor you can try right now

- Rich text CRDTs (Fugue + Peritext) not just LWW anymore

- Live cursors and presence

- React/Vue/Svelte adapters

- Multi-language servers (TypeScript, Python, Go, C#)

- 2,100+ tests, formally verified with TLA+

The demo shows character-level sync, slash commands, a community Word Wall, and offline editing. Disconnect your network, keep typing, reconnect - it merges automatically.

Known limitations:

- SDK undo/redo not yet wired into the demo editor (browser native works)

- No E2E encryption yet

Security note on the demo: LocalWrite is a public collaborative space with no authentication. Rooms are accessible to anyone with the URL and so don't share sensitive or personal data. The server sees all content in plaintext. Rate limiting and input validation are in place, but there's no content moderation or identity verification. Treat it like a public whiteboard.

GitHub: https://github.com/Dancode-188/synckit

npm: @synckit-js/sdk

Happy to answer questions about the CRDT implementation, architecture, or anything else.

Hey HN, I'm Daniel, creator of SyncKit.

I've been obsessed with the Ink & Switch "Local-First Software" vision for some time now—apps that work offline, feel instant, and give users control of their data. But every time I tried to build a local-first app, I hit the same wall: integration complexity.

The existing CRDT libraries (Yjs, Automerge) are incredible—they pioneered the algorithms that make local-first work. Kevin's optimization work on Yjs is masterful, and Automerge changed how I think about distributed systems.

But they're designed as modular primitives. You compose networking, storage, and conflict resolution yourself. That flexibility is powerful for complex systems, but it creates what I call the "Day 1 problem" for local-first: you spend 3 days wiring infrastructure before writing features.

I built SyncKit to solve this.

Different philosophy: Where Yjs gives you powerful primitives (build your own local-first stack), SyncKit gives you a pre-wired local-first database. Persistence, sync, presence—built-in, not plugins.

The technical approach: - Rust core with zero unsafe blocks (you can grep the codebase)

- TLA+ verified (explored 6.5M states to prove correctness)

- 154KB bundle (everything compiled together)

- 1,081 tests, 80 chaos tests

Performance: Competitive within 1-2ms of Yjs for standard ops. The win is local-first DX - one package that handles offline, sync, and conflict resolution.

What's included: - Rich text editing (Fugue algorithm for non-interleaving edits)

- Live cursors & presence

- Undo/redo (CRDT-native)

- IndexedDB persistence

- React/Vue/Svelte adapters

Built this in Nairobi, 9pm-3am. v0.1.0 got 601 stars in 3 weeks which honestly shocked me.

Try it live: https://synckit-demo.netlify.app GitHub: https://github.com/Dancode-188/synckit

Happy to answer questions about the TLA+ verification or the local-first architecture choices.

That's a fair point. The description does assume some familiarity with local-first patterns. I'll think about how to make the "why you'd want this" clearer for people outside that space. I appreciate the honest feedback

That's actually a really cool idea! Notes are just documents, so the sync model would work well. Hadn't thought about Obsidian specifically but I like it.

For P2P multiplayer with Svelte/SolidJS, SyncKit might not be your best fit because:

- It's client-server (not P2P)

- No Svelte adapters yet (coming in v0.2.0)

- Multiplayer games usually need P2P for lower latency

Better options for your use case:

- Jazz (jazz.tools) - Purpose-built for P2P collaborative apps

- TinyBase - Perfect signal model for Svelte/Solid, but you'd add your own sync

- Yjs - Mature CRDT with good P2P support

- RxDB - Heavier but has everything (queries, reactive, plugins)

If you went client-server instead of P2P, SyncKit would work once v0.2.0 adds Svelte support.

What's your preference? P2P or client-server? That'll determine the best fit.

You've hit on the core limitation because SyncKit has the same issue. Document/key-value like Loro and Yjs. The relational model problem is fundamental to CRDTs. They guarantee conflict-free convergence because documents are independent, but that breaks with foreign keys and joins. Can't have arbitrary SQL queries and guaranteed convergence without coordination.

ElectricSQL and PowerSync solve it differently (full SQL but weaker offline guarantees). For SyncKit, document-based state is an architectural choice, not something v0.2.0 will change.

I'm curious to know how you're working around this with Loro. Are you building your own query layer or are you keeping everything denormalized?

I appreciate the enthusiasm! And yeah, I'm planning to start blogging about the build process and some of the technical decisions probably after launch week settles down. I'll post about it on LinkedIn and in the GitHub Discussions when it's live. If you're following either, you'll see it!

Thanks for the interest!

See my response to skybrian above. You're both asking the same good question about the LWW messaging. Short version: system-level guarantees, not user-level concurrent edit preservation.

That's a great suggestion. The memory benchmark being buried is a fair point. I'll move it up top and create a proper benchmarks.md page. Thanks for the detailed feedback.

I haven't tried InstantDB yet, but it looks really interesting. Thanks for the pointer! Will definitely check it out.

You're right that this is confusing.

"Zero data loss" means system-level guarantees (no corruption from network failures, crashes, etc), not that concurrent edits to the same field are preserved. LWW definitely clobbers one of the edits.

What v0.1.0 does give you is field-level granularity (edits to different fields don't conflict) and guaranteed convergence (all devices reach the same state). But yeah, same field = last write wins.

The Rust core already has better CRDTs (Text, Counter, Set) that handle concurrent edits properly. They just need to exposed in the TypeScript SDK for v0.2.0.

I should clarify this in the docs. Thanks for pointing it out.

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?

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!

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

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.

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