Keyhive
Identity Platforms/FrameworksLocal-first access control library providing convergent capabilities (concap), group management CRDTs, and end-to-end encryption with causal key management (BeeKEM) for CRDT-based collaborative applications. Designed as a foundational authorization layer beneath identity — enables secure collaboration with read/write/admin roles, coordination-free revocation, and trust-minimized sync servers without requiring a central authority. Targets Automerge ecosystem but designed to be general-purpose for local-first applications .
Totalmente P2P Comunidade Risco de captura baixo
Detalhes
Licença Apache 2.0
Status de Dev Released
Proprietário Ink & Switch (independent research lab); Keyhive team: Alex Good, John Mumm, Brooklyn Zelenka (project lead)
País USA
Ano de Início 2024
Stack Rust, TypeScript, WebAssembly, Nix
Financiamento Ink & Switch research lab
Última Investigação 10 de mar. de 2026
Identity Toolkit / Platform Atributos
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)