Documentation
Learn how to use OCME Registry for content creation and verification
Reference
Architecture Overview
OCME Registry is a SvelteKit application deployed on Cloudflare Workers. It is the canonical system of record for OCME content identity: creators, content, media, splitsheets, showrunners, members, and cubes are registered here as DID documents and relational records.
Runtime and Storage
Canonical database (D1)
A Cloudflare D1 SQLite database is the canonical store for DID documents, content graphs, creators, splitsheets, play records, and settlement data. Schema is managed with Drizzle migrations. DID resolution reads only exact canonical D1 rows — the legacy KV fallback for DID documents is disabled.
Object storage (R2)
Cloudflare R2 buckets hold media source files, with a separate read-only binding for legacy content. Storage locations are tracked per media record and exposed through the authenticated service-binding API.
Key-value namespaces (KV)
KV namespaces serve supporting roles: cryptographic key material (KV-primary key storage with a local cache), technical media metadata, indexes, operation logs, deletion audit trails, and legacy document stores retained during the D1 migration.
Queues and workflows
Cloudflare Queues carry registry-first fanout: an index-rebuild queue, a RIC sync queue, and a RIC projection queue propagate registry writes to downstream broadcast surfaces. A durable Workers Workflow drives reconstruction settlement runs.
Identity Layer
Every registered entity carries a did:webvh identifier anchored to the registry domain (prod.ocmeregistry.com in production). DID documents are signed with RSASSA-PKCS1-v1_5 (SHA-256) over RSA-2048 keys, persisted
in D1, and resolvable by anyone over plain HTTPS at the public did.json endpoints. Public resolution
applies a privacy redaction boundary: payment and legal-identity material is stripped, and the document
proof is removed whenever anything was redacted.
Details: DID Method Guide and Content Verification.
API Surfaces
Public surface (unauthenticated)
- •
POST /api/verify/did— resolve and verify any supported DID - •
GET /creator/{id}/did.json,/member/{hash}/did.json,/showrunner/{slug}/did.json— DID document resolution - •
GET /api/health— liveness probe - •
/verify/*— browser verification tools
Service-binding API (authenticated)
/service-binding/* routes serve trusted
internal partners (the RIC gateway contract). Callers present a JWT issued by the OCMECO
app, validated server-side through the Sentinel auth service, and hold a creator, broadcaster, or admin role enforced per endpoint. Admin
operations (governance, settlement, D1 maintenance) live under /service-binding/admin/*.
Full endpoint inventory: API Reference.