How bytEM works
The vocabulary and shape of the system — not the wire formats. For how something is implemented, see the docs.
The four capabilities
bytEM answers four different questions about a piece of data. Each is a capability, not a storage layout — a deployment could serve all four from one place or four different ones without changing what they mean.
| Capability | Answers |
|---|---|
| Public index | What exists? |
| References | What connects to what? |
| Find | Where is it now? |
| Exchange | Give me the data |
The public index and search go together; find pairs with the store, not with the index — they are two distinct pairs of words, not synonyms for each other.
Access for agents
bytEM is not a website to scrape. The public index and search are open to anyone — that is what exists, and where to look. Everything past that point — the current data, the exchange, control over what you receive — runs over Matrix, and needs an agent that holds a Matrix identity.
This is deliberate. An agent with a Matrix identity has a name and a domain behind it, which means it can be recognised, whitelisted, rate-limited, or blocked. An anonymous fetcher can be none of those things. We would rather give you a durable, addressable way in than an open door that has to be narrowed later.
That identity is not a wall to climb before you start. It costs nothing to get, and you can go further up the ladder whenever you need to — you are not asked to commit to anything before you have seen whether the data is worth it.
| Identity | What it gets you |
|---|---|
| None | The public index, search, and DEID documents. What exists, and where to look. |
| Matrix guest | A demand room of your own. Provisioned in one click — no username, no password — but a real Matrix ID, so the room belongs to someone. |
| An account on this homeserver | An identity that outlives the session: your rooms, your history, your exchanges. Open registration at matrix.bytem.alpha.cities.app. |
| An account you already have | The same, under your own domain. matrix.org federates with us today; other homeservers on request. |
The two room types
A room is one or the other, and the assignment never changes once the room is created.
- Supply — a room that publishes data. It carries a DEID, a class, and the assets (datasets, APIs, web sources, and so on) that make up what it offers.
- Demand — a room that requests and receives data. It names the DEID it wants, and an exchange copies the matching supply room's assets into it.
Supply types
The delivery form of one published asset — how the data arrives, never what it means. The vocabulary is closed to these six:
| Supply type | Carries |
|---|---|
supply-type-dataset | A file: locator, name, schema, and licensing terms. |
supply-type-api | An endpoint: URL, name, schema. |
supply-type-html (Web source) | A web source: URL, name. |
supply-type-json | A small JSON payload, validated against a domain schema. |
supply-type-reference | A DEID reference published as an asset. |
supply-type-result | Computed output: source event, method, schema, extract. |
The two status tracks
Every DEID and every supply room carries two independent status values. Neither implies the other.
DEID status (entity_status)
Whether the DEID has been resolved against its governance domain.
local → registered
local— declared on this deployment only; the DEID does not resolve.registered— confirmed against the governance domain document; the DEID resolves. Once registered, the DEID is locked.
Market status (market_status)
Where a supply room sits in its commercial lifecycle. A room only ever moves forward through these values.
draft → reserved → advertised → exchangeable
draft— no advertisement published; the product is private.reserved— the DEID resolves.advertised— a supply advertisement has been published.exchangeable— class, assets and a registered DEID are all present.