Registry automation & security

Where things stand today

The parts that already exist and run: the manifest format and its canonical signing string (OMLA-MANIFEST-v1), the signed static registry under /registry/v2/ (a sequence index plus per-model artifacts, Ed25519-signed under a pinned registry key), browser-side verification that fails closed, and the resolver that turns manifests into payments.

The part that is deliberately not switched on: the automated publish endpoint. With the license now operative (OMLA-PL-2.1), submissions arrive by email, are validated with exactly the gates below, and are sequenced by hand. The endpoint ships once the manual pipeline is confirmed stable — automation must not outrun the legal instrument it registers.

The automated pipeline

Publishing is a seven-stage pipeline. A manifest either clears every gate or it does not enter the sequence — there is no partially-registered state.

1. Submit TODAY: BY EMAIL

   POST /registry/v2/submit with the signed manifest JSON and the submitting public key. No account, no session, no API key: the manifest's own signature is the authentication. Possession of the creator key is the only authority that exists in the system, so it is the only authority the endpoint asks for.

2. Validate

   Every gate in the table below, in order, fail-closed. Validation is pure — no state is written on failure, and the submitter gets the exact failing gate back.

3. Bind the version

   New model: assign the next sequence number. Update: the submission must carry an OMLA-MANIFEST-UPDATE-v2 binding — model id, signer, expected current version, hash of the previous manifest, timestamp, and hash of the new manifest — checked atomically so replays, races, and no-op updates are rejected. An update signed by a different key than the original is refused outright; keys, not names, own models.

4. Sequence

   The accepted manifest is appended to the sequence — append-only, no in-place edits ever. Each entry records the manifest hash, the sequence number, and the acceptance timestamp. Corrections are new entries; history is never rewritten.

5. Sign the snapshot

   The index (registry/v2/index.json) is rebuilt: full entry list, a Merkle root over the manifest hashes, a Merkle root over the complete artifacts, and the new high-water sequence number — then signed with the registry's Ed25519 key. The snapshot signature is over the whole state, so serving a stale or doctored index is detectable, not just individual manifests.

6. Serve & mirror

   The registry serves static files — no compute in the read path, nothing to inject into. Mirrors rsync the same signed artifacts; because everything is signed and sequenced, a mirror cannot alter anything without breaking verification, only serve or withhold it (and withholding is caught by the high-water check below).

7. Verify — everyone, every time

   Clients (the browser UI, the resolver tooling, a payer's script) verify before trusting: pinned registry key → snapshot signature → sequence high-water mark not lower than any previously seen (rollback detection) → per-manifest signature → weight hash against the downloaded artifact. Any failure shows nothing rather than something unverified.

Validation gates

Security model

No accounts, on purpose

There is nothing to phish, reset, or breach: authority is possession of a creator key, full stop. The flip side is stated honestly everywhere keys are made — lose the key, and the registry cannot help you update your own manifest. That trade is the design, not an oversight.

Registry key custody

The registry's signing key never lives on the web server. Snapshot signing happens in a separate signing step (operator-run today; an isolated signer when automated), so compromising the host that serves files does not yield the key that makes them trustworthy. Rotation is planned as an explicit, published event: a rotation statement signed by the old key endorsing the new one, kept permanently in the sequence, so clients can walk the chain from their original pin. Whole-site compromise resistance — an attacker who owns the origin and wants to serve a fresh-pinned fake history to brand-new visitors — requires independent mirrors or witnesses; that is phase 2, and until then the pin's first-visit trust honestly depends on the origin.

Append-only, with rollback detection

Nothing is ever edited or deleted in place, so "quietly changed" is not an available failure mode — only "stopped being served," and the client-side high-water check turns serving an older sequence into a hard verification failure, not a silent downgrade.

Names are labels; keys are identity

Display names are not unique and not defended — anyone can call a model "Llama-Improved." What verification proves is which key signed, and diligence means checking the fingerprint against where the weights actually live (the manifest next to the weights, the model card link). Name-squatting therefore gets an impostor nothing a payer's checklist doesn't catch, and disputes are handled in the open: evidence appended to the record, never silent edits.

Delisting

Removal (a false safety certification, CSAM, a court order) is itself an append-only event: a signed tombstone entry naming the sequence number and reason. Mirrors and clients see that a model was delisted and why — a registry that can silently un-happen things is worse than no registry. The one exception to slow process is the CSAM policy in Terms §6.3: immediate delisting plus mandatory reporting.

What the automated registry will never do

Hold funds, take usage or payment reports, require an account, or sit in the payment path. Automation changes how manifests get in; it changes nothing about OMLA's no-custody, no-knowledge posture.

Verification — what "trusted" actually means

For a browser or tool reading the registry: pinned key → signed snapshot → monotonic sequence → per-manifest signature. All offline-checkable; the registry page runs exactly this before showing anything.

For a payer about to send money, the five-minute diligence that makes payment safe:

1. Verify the manifest signature (the verifier — or any Ed25519 implementation, offline).
2. Check weight_hash against the model file you actually run.
3. Check the manifest is the one published next to the weights (repo, model card) — pointer-swapping is the attack; the signature makes it detectable, this step makes it detected.
4. Resolve the lineage with the resolver and eyeball the split — it is public precisely so you can.
5. Pay the pointers in the verified manifest, and keep your settlement sheet.

Every check above needs only public material. Anyone who asks you for a creator's key bundle or passphrase — including anyone claiming to be OMLA — is running a scam.

Rollout

The project plan on the about page tracks the same phases from the organizational side.