Transparency

What Codes stores

Its own SQLite database has these tables and nothing else: manifests, releases, release_log, trust, trust_history, playground_runs, plus the event outbox. That is release metadata keyed to Network app ids, trust tiers (metadata), validated manifests, and a log of playground runs (who ran what, the outcome and the problem code).

What Codes does not store

• Projects, members, apps, credentials, grants and quotas: OpenVibe.Network owns them; Codes shows what Network answers for the signed-in person.
• Client secrets: Network returns a new secret once, Codes shows it in that response and keeps no copy. Network itself stores only a hash.
• Access tokens: your Network session sits in httpOnly cookies in your browser; tokens a playground uses exist only for that request.
• Webhook secrets typed into the tester: used for one computation, then dropped.

What Codes does not do

• It does not enforce quotas: each service that owns a capability does (quotas are shown as recorded limits).
• It does not issue tokens or decide grants: Network does.
• Trust tiers never grant anything: authority comes only from grants.

Events it publishes

codes.app.published, codes.app.deprecated, codes.app.revoked when a release is published, deprecated or revoked (through OpenVibe.Events once its relay is configured).

Status

Stage alpha. Deployed and public since 2026-09-23: https://openvibe.codes is served by this portal (openvibe-ovh, unit openvibe-codes on 127.0.0.1:4900 behind nginx, release a9371c3), and the domain left OpenVibe.Sites. Sign-in uses the registered Network OAuth client `codes` (PKCE S256); the principal `codes` holds events.event.publish and the Events relay is configured. It is barely used yet: production holds 0 manifests, 0 releases and 0 playground runs. The external-developer path (account, project, sandbox app, grants, Media upload, app events) was run once on production on 2026-09-23 with public endpoints and curl, not through these playgrounds; that check is not committed to a repository or CI.

Works

• Sign-in with OpenVibe.Network (authorization code + PKCE S256), session tokens in httpOnly cookies
• Projects, members, apps, credentials (rotate, revoke), grants (request, approve, deny, revoke), quotas and audit over Network's /api/v1/projects API with the person's own token; Network's errors shown as Network answered them
• Project export (one JSON document: Network's project, members, apps, credential ids and hints, grants, quotas, audit for admin+, plus Codes' releases, manifests, trust and playground runs) and delete (owner: archive in Network first, then drafts and playground runs deleted, public releases revoked). Network has no project erasure endpoint, only archive
• Client secrets shown once, in the create/rotate response only, with no-store; never stored or logged (tested)
• Scope editor offering only capabilities apps can be granted (public, or partner when in the allowance)
• Docs generated at boot from the pinned openvibe-contracts and openvibe-sdk: contracts with field tables and fixtures, capability catalog, event types, SDK reference; service registry read live from Network with its health
• OAuth callback helper and a test callback that never exchanges the code
• Webhook tester for signature v1 and v2 (server or in-browser): decides as a receiver requiring v2 does, shows the timestamp's age and the ±300 s window, v1 shown but never deciding; signed sample deliveries carry v1, X-OpenVibe-Timestamp and v2
• Playgrounds (Media upload with media.object.upload, Events publish with events.app.publish) that run with the app's own token and refuse without the grant
• App and mod manifest validation; release metadata (draft, publish, deprecate, revoke) with codes.app.* events through the SDK outbox; trust tiers per ADR-013 (unreviewed, reviewed, first-party) as staff-set metadata, older names migrated at boot
• Policy pages rendered from the published ADRs; licensing read from package metadata; governance pages (code of conduct, contributing, contributor ladder, moderation policy) rendered from the repository's Markdown
• Release API guarded by openvibe-contracts requireCapability (codes.release.manage, codes.release.read)
• Readiness (/api/ready), /release.json and loopback-only /metrics

Not yet

• The playgrounds have never been used on production (0 playground runs); the one production end-to-end run used curl, and it is not a committed, repeatable check
• No usage, trace or error dashboards: no service reports per-project usage yet; quotas show recorded limits only
• Billing sandbox, Chat bot and Realtime playgrounds; CLI and scaffolding; templates
• Consent screen for third-party production apps (a Network gap)
• No JSON-LD or llms.txt on the public pages
• Governance material (code of conduct, contribution guide, contributor ladder, moderation policy) is written as drafts pending owner review: not in effect, not indexed