Entity Church Foundation

Applications

The substrate exists to be built on. This page is what that looks like in practice: the forms an application can take, what has actually been built, and what is still only a direction.

Most of the current work is here rather than in the substrate. The core protocol is small and has stopped moving much; the open questions now are about what you do with it. That means this page describes a lot of prototypes and a few running applications, and it is worth being clear which is which — so each thing below is marked.

You do not have to adopt all of it

The most common misreading is that using the entity system means committing to it entirely. It does not. There is a spectrum, and the shallow end is genuinely shallow — these four forms come from Application Architectures, which works them through properly.

The first form is a normal engineering decision you can make on a Tuesday. The last is a research position. They are both legitimate uses and the system is designed so you can stop anywhere along that line.

What has been built

Two reference applications, each a worked example rather than a product, and each deliberately built in a different language on a different implementation — if the paradigm only worked once, that would be worth knowing.

Entity Browser (Rust) is the larger of the two: a peer that runs in a web browser compiled to WASM, and the same application on the desktop in a native WebView. It is a window manager over the entity tree, where the window state itself is entities — so the tree is the data model rather than a store the application reads from. On top of that sit the surfaces you would expect an operating environment to have: browsing and editing the tree, a shell, consoles for dispatch and query, peer and connection management, key and storage management, an event and access log, a registry browser. And the ones that are applications in their own right: content sites and a site editor, a platform for running self-contained sandboxed HTML/JS apps over the tree, and chat and file transfer peer to peer — the last two are prototypes, which the project labels as such and so do we.

It ships as a research preview, with its caveats published alongside it — the development posture, the transports, and which storage durability claims are verified on which engine.

One use for it needs none of the network at all: a static site generator and publishing system. Author in the site editor, and what comes out is a signed, content-addressed tree you can put on any static host — so it functions as an ordinary site builder whose output happens to be independently verifiable, and whose author happens to be a peer. Nobody has to resolve a name, hold a pin, or know what a peer is to read the result; it is a website. Whether that is the most useful way in — a legible tool that does a familiar job, with the distributed properties available later rather than required first — is an open question this project is actively evaluating. See publishing on ordinary hosting.

Entity Workbench (Go) is the smaller and more deliberate one: a reference paradigm for an entity-native application, presented as something to learn from or lift from rather than to adopt. It ships a Go SDK over the kernel, a shell that is the primary interface (both a REPL and one-shot commands), a terminal renderer kept frozen as a discipline-enforcer, a desktop GUI, and a shared renderer-neutral application library the front-ends wire into — the point being that the front-ends are interchangeable because the application logic does not live in them.

Alongside those, a content-distribution corridor: small binaries that publish a peer's tree over plain HTTP and fetch it back, so published content can be served from ordinary static infrastructure and still be verified by the consumer. The pipeline from source through the tree to a live site is the one piece of this that has been run end to end against real infrastructure rather than a fixture — this site is served through it.

What has been explored, but is not built

These are prototypes, papers, or working designs. They are real work and they are not shipping software; several exist as an extension specification and a proof that the shape holds, without an application on top yet.

The part that has to be agreed

An application layer only converges if independent applications agree on format — the shape of the data, not the behaviour of the software. That is the discipline of the application-convention specifications: they define the entity vocabulary and the bytes, and deliberately say nothing about UI or application logic. Two conforming implementations produce compatible entities and render each other's content; beyond that they are free to differ.

The convention for rich content and the convention for content sites built on it are the ones with drafts today, and they have been worked jointly across more than one substrate. Everything else in this domain is plan rather than specification, and the project's own roadmap is explicit about the difference.

→ The application specifications

Named, with no design yet

Collaborative spaces and hosted repositories are named directions that will share the same navigation seam as content sites. There is no design for them today. They are listed here because leaving them out would make the roadmap look shorter than it is, not because there is anything to read yet.

The longer-term shape the work points at — an entity-native build system, content-addressed distribution of releases, peer-to-peer content delivery — is the same argument applied further out: these are all things that become straightforward if content addressing, verification and capability-checked access are properties of the substrate rather than things each tool reinvents. Whether that argument survives contact with the work is exactly what is not yet known.

Where to go next

If you are evaluating whether to build on this: the substrate is solid enough to build against, and the application layer above it is early. The first form on this page — using it as a library — is available to you now. The last one is a research programme, and worth engaging with on those terms.