Keyhive
Identity Toolkit / Platform
Community
Details
License Open source (Apache 2.0); github.com/inkandswitch/keyhive — Rust workspace with keyhive_core, keyhive_wasm (TypeScript bindings), beelay-core (auth-enabled sync)
Dev Status 🧪 Alpha
Dev Status Detail Pre-alpha (code opened for preview; 161 GitHub stars, 10 forks, 142 commits, 8 contributors, 67 releases; explicitly marked 'DO NOT use in production'; not yet security audited) Reclassified 2026-09-14: 'code opened for preview' across 67 releases means it's usable outside the core team, which is what separates Alpha from WIP.
Owner Ink & Switch (independent research lab); Keyhive team: Alex Good, John Mumm, Brooklyn Zelenka (project lead)
Governing Body Ink & Switch (independent non-commercial research lab)
Country USA (distributed research lab)
Start Year 2024
Stack Rust (95.4%); TypeScript (2.7%); WebAssembly (keyhive_wasm for browser integration); Nix (build system)
Funding Ink & Switch research lab (supported by individual and corporate sponsors and grants; independent research lab)
Last Investigated Sep 14, 2026
Identity Toolkit / Platform Attributes
Origins Local-first software / Access control (motivated by the need for production-grade access control in local-first applications without central servers — 'What would Signal for documents look like?'; inspired by Causal TreeKEM, Cryptree, DCGKA, UCAN, Matrix, Tahoe-LAFS)
Database CRDT-based (operates over Automerge documents; group membership managed as convergent CRDT state; no separate database — authorization state travels with data)
Query Language N/A (capability-based access via delegation graphs; no query interface — access determined by traversing convergent capability chains)
Data Formats Automerge Binary Format (compressed-then-encrypted CRDT operations); Ed25519/X25519 keypairs; ECDH shared secrets; BLAKE3 key derivation; Sedimentree (compressed encrypted causal commit graphs)
Mobile Support Via WASM SDK (keyhive_wasm compiled to WebAssembly for browser/mobile web contexts)
Web Support Yes (keyhive_wasm with TypeScript bindings; Automerge Discord channel for community support)
Native Apps Rust library (keyhive_core embeddable in native applications; no standalone app — infrastructure library)
Terms Open source (Apache 2.0); self-hosting; library integration
Funds Not separately disclosed (Ink & Switch is sponsor-funded research lab; Keyhive also involved in UK ARIA Safeguarded AI Programme via project GAIOS)
Based On Automerge (CRDT library); TreeKEM / Causal TreeKEM (CGKA protocols — BeeKEM is Keyhive's novel variant); DCGKA (Weidner & Kleppmann); object-capability model; UCAN; SPKI/SDSI; zcap-ld; Signal Double Ratchet (conceptual inspiration); Diffie-Hellman key exchange; BLAKE3 hashing
Permissions Apache 2.0 (open source) — keyhive, keyhive_core, keyhive_wasm, and beelay-core are all published under the Apache 2.0 license (permissive, patent grant included, commercial use allowed). Internal access control model uses CCAP (Convergent Capabilities), a capability-based delegation system where permissions are cryptographically bound and merge conflict-free — this is the runtime authorization model, not the software license.
Development Tools Rust workspace (cargo/rustup) — three crates: keyhive_core (core signing, encryption, delegation; Ed25519/X25519 keypairs, BeeKEM CGKA, capability chains, Sedimentree sync), beelay-core (auth-enabled sync protocol over E2E-encrypted data; RPC over HTTPS/WebSocket/TLS), keyhive_wasm (WASM wrapper around keyhive_core with TypeScript bindings via wasm-bindgen/wasm-pack); Nix flake for reproducible cross-platform development environment; GitHub Actions CI for native and WASM test pipelines. Integration target: Automerge CRDT documents (co-developed Beelay sync protocol). Pre-alpha; no security audit at time of writing; not recommended for production. Repository: github.com/inkandswitch/keyhive.
Authentication & Identity Deliberately excludes user identity — provides cryptographic authorization beneath identity layer. All entities identified by Ed25519 public keys (documents, users, groups, devices). Self-certifying delegation chains. Identity binding (name registration, user verification) explicitly left to layers above Keyhive
Storage Model Data encrypted-at-rest with causal key management; encryption boundaries based on Automerge Binary Format compressed chunks; symmetric keys for each chunk with causal predecessor key inclusion; Sedimentree for probabilistic compression and encryption of CRDT updates
Interoperability Automerge ecosystem (primary target); designed to be general-purpose for any local-first application; beelay-core provides auth-enabled sync protocol; Automerge Discord community; planned integration with broader local-first ecosystem
Data Portability Full portability (user controls keypairs; authorization state travels with data in CRDT; no central server dependency; capability chains are self-certifying and portable)
Governance & Decision Making Ink & Switch research lab (independent, non-commercial research lab; open-source community contributions via GitHub; Code of Conduct; Contributing guidelines)
Identity Standards Not applicable in traditional sense — Keyhive deliberately operates below identity standards. Uses Ed25519/X25519 cryptographic keys as identifiers; convergent capabilities (concap) as novel access control primitive between object-capabilities and certificate-capabilities (UCAN, zcap-ld)
Identity Standards - List
DID Methods Supported None (deliberately excludes identity layer; entities identified by raw Ed25519 public keys rather than DIDs; DID binding left to layers above)
DID Methods Supported - List
Key Management User-controlled Ed25519/X25519 keypairs per device; BeeKEM (novel Continuous Group Key Agreement protocol) for group key management with logarithmic performance; Diffie-Hellman key exchange at tree nodes; BLAKE3 key derivation function for ratcheting; periodic key rotation for post-compromise security; causal key chains for encrypted chunk access
Credential Types Convergent capabilities (concap): stateful, CRDT-based capability tokens that sit between object-capabilities and certificate-capabilities; delegation chains with read/write/admin/pull access effects; group membership as implicit credential
Credential Types - List
Verification Method Cryptographic signature verification (Ed25519); self-certifying delegation chains (each capability cryptographically proves authorization path); ECDH shared secrets for encryption/decryption; no external verification service required
Privacy Features End-to-end encryption (data encrypted-at-rest; sync servers see only random-looking bytes); trust-minimized sync servers (cannot read plaintext); pull access control (restricts even retrieval of ciphertext to authorized parties); post-compromise security via BeeKEM key rotation; forward secrecy sacrificed for CRDT compatibility (requires full causal history) but concurrent/future chunks remain secret
Authentication Methods Cryptographic signatures (Ed25519); capability delegation chains (self-certifying); no passwords, no usernames, no external auth providers — purely cryptographic
Revocation Mechanism Coordination-free revocation via convergent capabilities; BeeKEM tree blanking (revoked member's leaf and path blanked; concurrent operations by revoked members guaranteed not to survive); group CRDT handles concurrent add/remove conflicts deterministically
Agent Types Supported Public keys representing: documents, users (individuals), groups (teams/organizations), devices (user device management behind proxy identities); designed to be extensible to any entity representable by a public key
Wallet/Client Types SDK/Library integration (Rust crate keyhive_core; WASM package keyhive_wasm with TypeScript bindings; beelay-core for sync); no standalone wallet — embeds into applications
Recovery Mechanisms Not yet specified (pre-alpha; key loss recovery mechanisms not documented; device management via group delegation provides some redundancy — multiple devices behind a user proxy)
Compliance / Regulations Not applicable at current stage (pre-alpha research project; explicitly excludes FIPS compliance as antigoal; no security audit performed; privacy-preserving by design via E2EE)
Credential Exchange Protocols Convergent capability delegation (signed delegation graphs traversed locally; no external exchange protocol — capabilities travel with CRDT data via sync); beelay protocol for auth-enabled sync
Credential Exchange Protocols - List
Trust Framework Cryptographic capabilities only (no central authority; trust rooted in Ed25519 key ownership and delegation chain verification; trust-minimized sync servers; designed for environments ranging from 'planning a surprise party' to 'journalists and activists')
Cost Model Free / open source (Apache 2.0; research project; no commercial offering)
Censorship Resistance High (no central authority; E2EE data; trust-minimized sync servers interchangeable; authorization travels with data; designed for peer-to-peer and offline operation under arbitrary network partition)
Relationships
How this tool connects to other tools and organizations, from relationships reviewed by the OpenHaven data steward. They describe how projects connect, not how good they are.