Keyhive
Identity Toolkit / Platform
Comunidade
Links
Detalhes
Licença Open source (Apache 2.0); github.com/inkandswitch/keyhive — Rust workspace with keyhive_core, keyhive_wasm (TypeScript bindings), beelay-core (auth-enabled sync)
Status de Dev 🟢 Ativo
Detalhe do Status de Dev 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)
Proprietário Ink & Switch (independent research lab); Keyhive team: Alex Good, John Mumm, Brooklyn Zelenka (project lead)
País USA (distributed research lab)
Ano de Início 2024
Stack Rust (95.4%); TypeScript (2.7%); WebAssembly (keyhive_wasm for browser integration); Nix (build system)
Financiamento Ink & Switch research lab (supported by individual and corporate sponsors and grants; independent research lab)
Última Investigação 9 de mar. de 2026
Identity Toolkit / Platform Atributos
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)
DID Methods Supported None (deliberately excludes identity layer; entities identified by raw Ed25519 public keys rather than DIDs; DID binding left to layers above)
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
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
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)