Entity Church Foundation

ECDEOS — the distributed entity operating system

You are reading this through it. Every site in this constellation — the Foundation, the protocol, the registry, the lab — is served by ECDEOS. The page in front of you was published out of an entity tree and rendered by the same application you can run as your own peer.

That is the short argument for the whole thing. It is an early-stage research prototype and it is what delivers the project's own content.

The same model, one layer up

The protocol has three reference implementations — Go, Python and Rust — written independently against the same specification. That is how the core is shown to be real: not by argument, but by more than one team building it and the results agreeing on the wire.

ECDEOS applies the same method one layer up. Two reference implementations of the operating-system layer, in different languages on different cores:

Neither is a client talking to a server. Each is a full peer with real handler dispatch and real multi-peer state, and the entity tree is the data model rather than a store the application reads from.

They are aligned by the application-layer conventions — the L5 format specifications that say what the data looks like and say nothing about the user interface. Two implementations converge on the bytes and stay free to differ about everything else. Same discipline as the core, one layer up.

What it does

Applications. Two kinds, and the difference matters.

Entity apps are self-contained HTML/JavaScript bundles. One file, no network access, ingested into a peer's tree as content-addressed data and run inside a sandboxed iframe that talks to the host over a small message protocol. Save state goes back into the tree, so it travels with the peer rather than living in a browser's local storage. The same bundle publishes to ordinary static hosting and is fetched on click. There is a written contract for what an entity app is, so this is a target you can build against rather than a demo — the app author owns the app, and the substrate provides identity, content addressing, durable storage and distribution.

Entity native programs run compute on the substrate rather than JavaScript in a sandbox — and they are the clearest thing to point at when asking whether the two implementations actually agree. The built-in programs were authored in Entity Workbench, on the Go side, and are imported into Entity Browser hash-verified. Written once, run on the other implementation, checked by content address rather than trust. They run behind the same isolation boundary the entity apps use; compute never runs on the system peer.

Content sites. Browse entity-native sites, and make your own — there is a site browser and a site editor, and publishing goes out to static hosting so a reader can verify what they fetched. What gets pushed is a signed, content-addressed tree, which is why commodity static hosting is enough and the peer that published it does not have to stay online: publishing without a server.

Chat and file transfer, peer to peer, over the same substrate. Both are prototype-stage and honestly labelled as such below.

And the peer itself. Because the operating system is the peer, the machinery is not hidden behind it: a shell, execute and query consoles, the entity tree directly, event and access logs, key and storage management, a registry browser, a knowledge base. An operating system you can open up is the point rather than a developer concession.

How these sites actually reach you

The publishing path is worth describing, because it is the part that has been run end to end against real infrastructure rather than a fixture.

A site is authored into a peer's entity tree. The tree is exported to a static directory — pages, assets, and a manifest — and served from ordinary static hosting. No application server, no database, nothing dynamic at the origin. What arrives in your browser is the same application that authored it, booting as a peer and reading the published tree.

Names resolve through the registry. It is a working registry, not an illustration: it serves the name → peer indirection these sites use, and the reader's own registry is meant to be the interesting one — a pin is explicit, and there is no default registry in any protocol sense.

The published form has more than one shape, and which one a deployment uses is a choice:

The constellation runs these deliberately at different settings, because working across independent publishers from a real host is what exercises the resolution layer properly — and what turns up the things worth fixing.

The sites: Entity Church Foundation · Entity Core Protocol · Entity Church Registry · Bill's Lab.

Technical detail

Transports, and the constraint that shapes them. A browser tab cannot open a raw TCP socket. That single fact drives most of the connectivity design: a TCP-only peer is simply unreachable from a tab, so a tab reaches a listening peer over WebSockets, and reaches another browser over WebRTC. Native and desktop backend peers are not limited this way and can listen on TCP directly.

Browser-to-browser needs an introduction, and only an introduction. Two tabs cannot find each other unaided, so they meet at a rendezvous node — by agreeing on a name out of band, or by naming a peer id directly. Two properties are worth stating because both are easy to assume away: rendezvous introduces, it never sits in the data path, and it never authorizes. The connection that follows runs the ordinary handshake and capability flow, and a peer id discovered this way is a claim until you connect and verify it.

The desktop build runs the same application in a native WebView, with a separate native backend process that can spawn peers which listen properly and persist to disk.

Storage is the browser's durable storage in a tab, and a real database for backend peers.

Where it actually is

A research preview — suitable for evaluation and exploration, not a hardened production deployment. The caveats are published with it and are worth reading before you deploy anything: the posture is development-focused, with open grants on backend peers and plaintext transports; storage durability is confirmed on one browser engine and not yet verified under the desktop WebView. Chat and file transfer work and are prototypes. Much of the application layer is still being worked out, and the conventions holding the two implementations together are drafts.

And the honest gap, which is the thing we would most like help with. Almost all of the effort here has gone into specification and implementation. This has not been lived with. Nobody has run it across a home network for a month, moved real files with it, leaned on sync and revision until something broke, or found out what it is actually like to use day to day. Those are exactly the questions the code cannot answer about itself, and they are open.

So the useful contribution right now is not a patch. It is running it, trying to do something real with it, and telling us what went wrong or made no sense. Being told what is broken is worth more to us than being told it is interesting.

The relationship to the protocol stays the same as everywhere else in this project: the core is a substrate, and this is a reference implementation on top of it. Running a peer never requires running ECDEOS, and a peer that implements the core and none of this is a fully conformant peer — the same way the three core implementations demonstrate the protocol without being the protocol.

Try it

Both implementations build and run from their repositories, and the browser one needs only a browser tab to be a real peer.

Issues and contributions go to the repositories.