Elohim Protocol

Integrated P2P Runtime

A peer-to-peer substrate for content that carries its own knowledge, value and governance. Its unit is the Elohim Protocol Record (EPR): a deterministically encoded (DAG-CBOR) record with a CIDv1 content address and a signed envelope that says what the content is, who stewards it and what economic flows attach to it, and which governance decides how far it may travel (its 'reach', a ladder from private to commons). Holochain 0.7, in a pinned fork, is the 'notary floor': five DNAs hold the rules for identity, shared content, community proposals and judgments, node capacity and a node registry. A storage sidecar moves content-addressed bytes between peers over libp2p and iroh, and 'doorways' project the network to ordinary browsers over HTTP and DNS, so people without a node can take part; a person can start hosted by a doorway and move to their own device later. Economics are modelled as ValueFlows / REA events rather than a token. The design also includes AI agents bound by a written constitution and acting under each person's authorisation. The project's own status statement of September 2026 separates what runs today, a test household mesh and a small alpha fleet of doorways, storage and conductors, from what is designed but not yet running, which includes the agent runtime .

Community
Links
Visit Website See this tool in the graph Suggest an edit

Details

License Mixed, per component, with no repository-level licence: the README says licensing is per crate and package today and that a root licence and a single policy are an open decision, and that the licence a contribution lands under is not settled. Declared in the crate manifests: CAL-1.0 for the EPR codec and the ValueFlows / REA crates; AGPL-3.0 for the storage sidecar and the SDK crate; Apache-2.0 for the doorway, eprfs, the steward node, the compute types and as the Rust workspace default; MIT OR Apache-2.0 for the relay beacon. The Holochain DNA and zome manifests declare no licence. https://github.com/ethosengine/elohim
Dev Status 🧪 Alpha
Owner Ethosengine, the developer's personal organisation (the GitHub organisation describes itself as 'an ambitious personal org exploring digital infrastructure for human flourishing through family scale computing'); no legal entity is stated
Governing Body None beyond the single steward: one developer holds the repository, roadmap and alpha infrastructure and a maintainer merges to the development branch; the project describes a 'council of elohim' (an earned roster of AI agents) as the designed way to decide which version of the network's rules is canonical, but not yet in use
Country United States (the organisation profile and the README place the developer in the US)
Start Year 2025
Stack Rust (EPR codec, storage sidecar, doorway, steward node); Holochain 0.7 conductor, a pinned fork, with DNAs and zomes in Rust; libp2p and iroh for byte transport; TypeScript and Angular web apps; a Tauri desktop app; WebAssembly; Gherkin scenarios as the specification; just as the command runner .
Funding Self-funded by the developer, per the submission to OpenHaven; the README carries a donation link and names no grant or investor
Last Investigated Oct 29, 2026

Topology view

This tool in the centre and the things it is directly related to. Each line names the kind of relationship.

Topology view: Elohim ProtocolThis tool in the centre and the things it is directly related to. Each line names the kind of relationship.ElohimProtocolActivityPub (Aims to interoperate with)ActivityPubIroh (Based on)IrohPKARR (Based on, Interoperates with)PKARRValueflows (Based on, Requires, Speaks protocol)ValueflowsHolochain (Built on, Stores in)HolochainDIDs (Conforms to, Identifies via, Speaks protocol)DIDsdid:key (Interoperates with, Speaks protocol)did:key
  • ActivityPub (Tool): Aims to interoperate with
  • Iroh (Tool): Based on
  • PKARR (Tool): Based on, Interoperates with
  • Valueflows (Tool): Based on, Requires, Speaks protocol
  • Holochain (Tool): Built on, Stores in
  • DIDs (Tool): Conforms to, Identifies via, Speaks protocol
  • did:key (Tool): Interoperates with, Speaks protocol

Open in Graph Explorer

Use Case Domains

Platform Evolution & Sovereignty Co-Creation & Knowledge Identity & Trust

Affordances

Gradual decentralization Self-hostable Data portability Provenance tracking Version history Interoperable formats Sovereign identity

Integrated P2P Runtime Attributes

Origins Digital infrastructure the project describes as organised around love, in which every record couples knowledge, value and governance from the start, and community-governed AI agents act under a written constitution rather than trained values. The project says its design draws on Judeo-Christian thought as a chosen lens, not a claim on the territory, and takes its name from the Hebrew elohim; its layers carry Hebrew and Latin names (imagodei, lamad, avodah, qahal, shefa, mishpat). It builds on ValueFlows, Holochain and the Metacurrency Project lineage, and on IPLD-style content addressing .
Database Holochain source chains and a distributed hash table per DNA for the authoritative records; the storage sidecar keeps chunked blobs and capability advertisements locally
Query Language HTTP APIs on the storage sidecar and the doorway; a ValueFlows GraphQL (vf-graphql) endpoint is mounted by the storage sidecar through a hREA bridge crate
Data Formats Deterministic DAG-CBOR envelopes with CIDv1 identifiers and Ed25519 signatures; an `epr:` URI scheme aligned with IPLD; TypeScript bindings generated from the Rust types; W3C DID documents (did:key and did:elohim)
Collaborative Live Editing Not stated by the project.
Rich Text Editing Not stated by the project.
Mobile Support Partial: the hardware specification says modern smartphones can run a local Holochain conductor for lightweight apps, but the packaged steward app is a desktop app and no mobile release is linked; the alpha apps are web apps reached through a doorway
Web Support Yes: Angular web apps are served at alpha.elohim.host through a doorway, and a visitor consumes through the doorway without becoming a peer
Native Apps A Tauri desktop steward app that embeds a Holochain conductor for self-custodied keys, and a headless always-on node runtime; both build from source and no packaged release is linked
Terms The alpha apps are free to use at alpha.elohim.host; code is under the per-component licences above; the developer accepts donations
Funds Not stated by the project.
Based On Holochain 0.7 (pinned fork), iroh, libp2p, ValueFlows / REA, W3C DID, IPLD content addressing (DAG-CBOR, CIDs), pkarr for endpoint records
P2P Architecture Agent-centric: each person keeps a signed source chain validated by peers through a Holochain DHT, with no global consensus; a separate content-addressed dataplane moves bytes over libp2p and iroh. Participation has four tracks (notary, storage peer, spoke, doorway) that a device can combine
Overlay Network Holochain networks (one per DNA hash) plus libp2p and iroh swarms for bytes; doorways are HTTP gateways that proxy to a conductor and a storage peer and do not join the swarms themselves
Content Addressing Yes: CIDv1 identifiers over deterministic DAG-CBOR; the same identifier resolves whichever transport delivered the bytes
Local-First Partial: App and Node Stewards run their own conductor and storage and hold their own keys, but the Hosted stage keeps keys and runs the person's cell on a doorway's conductor, and the design aims at moving between stages without loss
E2EE Not described in the cited sources: reach labels decide who may be served a record, and the hardware specification mentions encrypted backup shards, but no end-to-end encryption scheme for content is specified there
CRDTs Lib No CRDT library of its own is described; the specification lists an Automerge document-sync protocol identifier (/elohim/sync) among its protocols
Byzantine Fault Tolerance Partial, through Holochain: records are validated by peers against the DNA's rules and notarised once the DHT holds them across enough peers; the project does not describe a separate Byzantine fault-tolerance protocol
Signature Yes: Ed25519 signatures on EPR envelopes and on Holochain source-chain records
Permissions Reach labels (eight rings from private to commons) declared in the record and checked by a conforming peer before serving; a first authoring gate on the storage path checks whether a signer may declare a reach; gating reach by earned standing is designed, not running
Semantic Web Compatibility Partial: ValueFlows ontology through a hREA / vf-graphql bridge, W3C DIDs and IPLD alignment; no RDF or SPARQL layer is described
Smart Contract N/A: no ledger or smart-contract layer; validation is Holochain DNA rules and a settlement-bridge interface for other economic rails is in a research phase
Protocol Stack Position Application and storage layers over libp2p and iroh transports and Holochain; doorways project to HTTP, DNS and TLS
Asset / Value Embedding Value is carried in the record: each EPR couples economic events (ValueFlows / REA) to its knowledge and governance. No token has been issued; a token crate ('default economic rail', settlement bridge interface and token primitives) is in a research and specification phase, and the specification calls token types readings of economic events, not separate currencies
Development Tools A root command runner (just) with gate, test, dev, mesh, seed, look, status and codegen recipes; Gherkin scenarios as the specification; an `epr` command-line tool in eprfs; TypeScript SDK and generated bindings; an Eclipse Che hosted workspace
Deployment Options A hosted alpha fleet (doorways, storage, conductors) at alpha.elohim.host; a local stack (`just dev start`); a multi-peer household mesh on one machine (`just mesh start`); a desktop steward app and a headless node runtime built from source
Authentication & Identity A person's identity is their Holochain key; the Hosted stage keeps it on a doorway's conductor and the design lets it be exported to the person's own device; stewards sign in at their own runtime's portal; doorways publish a W3C DID document and sign pkarr-format endpoint records (publishing not yet wired); recovery is designed to be social
Storage Model Authoritative records on Holochain DHTs; bytes in chunked, content-addressed blobs held by storage peers, with the storage sidecar keeping its holdings aligned with the DHT's list of what should exist; doorways cache projections and are never the source of truth
Interoperability ValueFlows (hREA / vf-graphql bridge), W3C DIDs (did:key, did:elohim), pkarr, IPLD alignment; AT Protocol and ActivityPub bridges are planned and not running
Social Graph Built into the design: imagodei records people, their attestations about one another and relationships, and standing is described as a relational track record rather than a score; the social-graph features are at the design and alpha stage
Protocol Maturity / Standardization A written specification, version 0.2 (September 2026), defines the EPR resolution protocol, the `epr:` URI scheme and an IPLD alignment, with a feed protocol specified but not implemented; no standards-body involvement; the implementation is alpha
Update Policy Records are immutable and addressed by content; withdrawing a claim means issuing a superseding record. Network rules evolve by new DNA versions that peers adopt by choice, since a DNA's hash is its network's identity; which lineage is canonical is designed to be decided by a council of agents, not yet in use

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.

Aims to interoperate with
Based on
Built on
Conforms to
Identifies via
Requires
Speaks protocol
Stores in
Interoperates with