The OMI spec is under heavy development, and every piece of it is subject to change. We are documenting the core primitives for sovereign application lifecycles. Join us in defining the v1.0 draft.
Developer Identity & Namespace Registration

Developer Identity & Namespace Registration

The App Registry is the center of the swarm’s cryptographic identity management, acting as not just the authoritative source for developer namespaces and their associated public keys, but also as the foundational trust anchor for all subsequent application and service registrations.

Objective

Establishing a sovereign cryptographic identity and claim a unique namespace within a registry.

The App Registry is “Zero-Knowledge”. It only stores public keys and endpoints. It cannot see user data, application logic, or private content.

Prerequisites

  • A local environment with cryptographic tools installed (or equivalent crypto library) for generating and managing key pairs.

The Protocol Workflow

  1. Key Generation: The developer generates two distinct types of keys on their local machine:

    • Master Key-Pair: The primary keys used for daily administrative tasks and service provisioning.
    • Guardian Key-Pair: A high-security backup key-pair intended for Identity Recovery.
  2. Registry Selection: The developer selects a target App Registry (e.g., omiappreg.org) to host their developer profile.

  3. Registration Payload: The developer constructs a JSON payload to claim their identity, including both the active master key and the recovery keys:

    provisional payload
    {
      "version": "1.0",
      "data": {
        "public_key": "m2bi0ja8bgkq9ki...",
        "guardian_public_keys": [
          "g9v2n8x3p1l0q..."
        ],
        "namespace_claim": "alice",
        "contact_email": "alice@devagency.com",
        "metadata": {
          "website": "https://devagency.com",
          "organization": "Dev Agency"
        },
        "timestamp": 1705412400,
        "nonce": "8f3k2l9a"
      },
      "signature": "3c8e9f1a2b3c4d5e6f..."
    }
  4. Submission & Verification: The payload is sent to the App Registry. The registry performs the following validations:

    • Namespace Availability: Verification that the requested namespace (e.g., alice) is not already registered.
    • Signature Integrity: Verification that the signature matches the public_key provided in the data block, by doing self-signature verification.
    • Identity Proof: The registry sends a verification email or uses another method, like a small “anti-spam” payment to activate the account.
  5. Activation: Once verified, the App Registry records the association:

    • namespace “alice” ↔ master_public_key
    • namespace “alice” ↔ guardian_public_keys (Immutable Genesis Record)
Security Note: Private keys never leave the developer’s local machine. The Guardian Private Key should be moved to “Cold Storage” (offline) immediately after generation.