App Registry
In the OMI ecosystem, the App Registry is the Source of Truth. It is the central nervous system of your swarm, acting as a specialized “Service DNS” that tells every component who to trust and where to find their peers.
While a traditional DNS maps domain names to IP addresses, the App Registry maps an AppID to its entire cryptographic and operational blueprint.
The Core Responsibility
The App Registry isn’t just a database; it’s a Discovery and Governance Engine. It manages three critical pillars of the swarm:
- Identity Anchor: It holds your Master Public Key. This is the root of all trust—every service binding or configuration change must be verified against this key.
- Service Directory: It maintains the “Service Manifest,” a real-time list of every Domain Service (CMS, CRM, etc.) currently bound to your app, including their endpoints and individual Public Keys.
- Backbone Configuration: It defines the Core Services (Auth, Billing, Logging) that the swarm must use. When a new service joins, the Registry hands it this “operational map.”
Why this is different from “Standard Service Discovery”
In a traditional “CRUD State of Mind” architecture, service locations and API keys are often hard-coded into environment variables or hidden in proprietary cloud consoles. The App Registry replaces that “static glue” with dynamic sovereignty.
Late-Binding Infrastructure Services are not “hard-wired” to each other. If you move your database from one provider to another, you don’t update five different config files. You update the Registry once. The rest of the swarm “resolves” the new location instantly.
The “Double-Kill” Security Model The Registry acts as a cryptographic circuit breaker. If a Domain Service is compromised, the developer sends a Signed Termination Request to the Registry. The Registry then broadcasts an invalidation signal, effectively “de-platforming” the compromised service from the swarm in seconds.
Provider Independence The Registry is a protocol, not a silo. Because it uses the OMI standard, you can use a public Registry, a community-run one, or host your own for ultimate privacy. The services don’t care who hosts the Registry—they only care that the data inside it is signed by your Master Key.
What lives in the Registry?
| Field | Purpose |
|---|---|
| AppID | The unique, global namespace for your application (e.g., org.omiappreg.alice.app). |
| Master Public Key | The cryptographic root. Only requests signed by the matching Private Key can modify the Registry. |
| Guardian Keys | “Emergency” keys kept in cold storage for identity recovery if the Master Key is lost. |
| Backbone Manifest | The URLs and keys for your Auth, Billing, and Logging providers. |
| Service Records | A list of active Domain Services, their URLs, and their unique Service Public Keys. |
The Registry Workflow: “Resolving” the Swarm
When Service A (a frontend) needs to talk to Service B (a database), it doesn’t just send a request into the void. It follows the OMI resolution path:
- Resolve: Service A asks the Registry: “Where is the Database for AppID X, and what is its Public Key?”
- Verify: The Registry returns the signed record.
- Handshake: Service A now knows exactly where the Database is and can verify its identity using the key provided by the Registry.