GuardianDB
Guardians
Blog
GitHub Documentation
docs.rs Documentation
Sentinel TUI
willOS<br>Messenger
GuardianDB<br>Blog<br>GitHub Documentation<br>docs.rs Documentation<br>Sentinel TUI
Guardians<br>GuardianEngine
Why GuardianDB<br>A database that lives on every device
GuardianDB began as a Rust port of OrbitDB, but it's no longer "OrbitDB in Rust". The legacy<br>IPFS / CID / libp2p stack is gone, replaced by Iroh's QUIC transport, BLAKE3 hashing, and<br>Willow range-based set reconciliation.
Local-first & offline
Every node holds a full replica. Reads and writes never touch a server, so your app keeps working with no connection at all.
True peer-to-peer
Direct, encrypted connections via Iroh's Magicsock. NAT traversal, hole punching and Wi-Fi ⇄ 5G roaming with no global DHT.
CRDT conflict-free sync
Last-Write-Wins CRDTs and a causal DAG mean concurrent edits converge automatically. No merge conflicts, no coordinator.
Blazing fast
Willow transfers only the diff between peers, millions of records in milliseconds. BLAKE3 + QUIC keep hashing and transport hot.
Secure by design
Each peer is an Ed25519 identity (its 32-byte address). Every connection is end-to-end encrypted out of the box.
Multiple store types
Event Log, Key-Value, and Document stores. Plus an optional TypeORM/Mongoose-style ODM with schemas, indexes and CRUD.
Under the hood<br>The technology stack
Modern, no-compromise building blocks chosen for performance, safety and decentralization.
🦀 Rust Edition 2024, memory-safe, fearless concurrency
Iroh QUIC-based P2P endpoint & data sync
QUIC transport One encrypted socket multiplexes data, state & gossip
BLAKE3 Fast cryptographic content hashing
Willow Range-based set reconciliation (diff-only sync)
Iroh-Docs Last-Write-Wins CRDT for KV & Document stores
Iroh-Gossip Epidemic broadcast trees for real-time signals
Ed25519 Identity = address (32-byte public key)
Postcard Compact binary serialization (no JSON overhead)
redb Embedded, zero-copy local storage engine
Tokio Async runtime powering every operation
CRDT Log Causal DAG with Lamport clocks & ACLs
Coming from IPFS / OrbitDB<br>What changed under the hood
ConceptLegacy (IPFS / OrbitDB)GuardianDB (Iroh)
IdentityPeerID (Multihash)EndpointID (Ed25519, 32 bytes)<br>Content IDCID (SHA-256 + codecs)Hash (BLAKE3)<br>Networklibp2p swarm (TCP / WS)Iroh Endpoint (QUIC)<br>DiscoveryKademlia DHT (global)Pkarr / DNS + mDNS, direct<br>Data formatIPLD DAG (JSON)Binary (Postcard)<br>SyncBitswap (block-by-block)Willow (range-based)
main.rs
use guardian_db::guardian::GuardianDB;<br>use guardian_db::p2p::network::client::IrohClient;
#[tokio::main]<br>async fn main() -> Resultdyn std::error::Error>> {<br>// Start a local Iroh node and open a persistent database.<br>let client = IrohClient::development().await?;<br>let db = GuardianDB::new(client, None).await?;
// Open a key-value store — writes replicate to peers automatically.<br>let kv = db.key_value("settings", None).await?;<br>kv.put("theme", b"dark".to_vec()).await?;
if let Some(v) = kv.get("theme").await? {<br>println!("theme = {}", String::from_utf8_lossy(&v));<br>Ok(())
Frequently asked questions<br>Everything you want to know
What is GuardianDB for?
GuardianDB is for building applications that need peer-to-peer synchronization, offline-first operation, and high performance without a central server . Every node keeps a full local replica, so reads and writes happen locally with no network round-trip, and changes converge across peers automatically over Iroh.
It's a great fit when you want your data to be owned by the people using it, to keep working with zero connectivity, and to sync directly between devices and users when a connection is available.
What are the use cases of GuardianDB?
Anywhere central servers are a cost, a bottleneck, or a single point of failure:
Local-first & offline-first apps : note-taking, editors and productivity tools that must work with no connection.
Real-time collaboration : shared documents, whiteboards and multiplayer state via CRDT merging.
Decentralized & Web3 apps : user-owned data with no backend to operate.
Edge & IoT : devices that sync directly with each other on a LAN or across the internet.
Messaging & presence : direct encrypted channels and real-time gossip signaling.
Audit logs & event sourcing : the append-only Event Log store keeps a tamper-evident, causally-ordered history.
How do I scale GuardianDB?
Because there's no central server, you don't scale a bottleneck, you add peers and tune how they connect and sync.
Reads & writes are local , so read throughput scales linearly with the number of nodes; writes apply locally and propagate asynchronously.
Sync cost is proportional to the diff, not the dataset .Willow range-based reconciliation only exchanges what two peers are missing, so steady-state sync stays cheap as data grows.
Tune connectivity with enable_discovery_mdns (LAN), enable_discovery_n0 (global Pkarr/DNS) and known_peers for bootstrapping.
Turn the knobs that matter...