At this level
dev.cocore · 1- dev.cocore.account.createApiKey procedure Mint a new cocore API key for the authenticated account. Authenticate with either a console session cookie or an existing `Authorization: Bearer cocore-...` key. The full secret is returned exactly once in `secret` and is never retrievable again — only its SHA-256 hash is stored. Use the returned key to authenticate subsequent automated requests (inference, the record proxy, and these key-management methods themselves).
- dev.cocore.account.defs defs Shared type definitions for dev.cocore.account.* methods.
- dev.cocore.account.deleteApiKey procedure Hard-delete one of the authenticated account's API keys, removing the row entirely (no audit trail recovery afterwards). For most flows revokeApiKey is preferable; use this to clean up revoked or expired keys you no longer want listed. Scoped to the caller's DID. Idempotent: deleting an unknown key returns `deleted: false`.
- dev.cocore.account.friend record A one-way declaration that the publishing DID trusts the subject DID enough to route private (friends-only) compute jobs to them. Friending is *not* mutual and *not* a permission grant for the subject — it's the friender's own routing preference. The subject does not need to consent, sign anything, or even be aware. Published to the friender's PDS; multiple records for the same subject are tolerated (the rkey is `tid`) but the console deduplicates on upsert so steady state is one record per (fri
- dev.cocore.account.getProfile query Full profile-page payload for one DID: account fields, machines they own, activity counts, and incoming-friends count, in a single round-trip. When the DID has not published a `dev.cocore.account.profile` record locally, handle/displayName/avatar are hydrated from the public Bluesky AppView.
- dev.cocore.account.listAccounts query Discovery directory of every signed-up DID (any DID with a record under `dev.cocore.*`), joined with profile + provider counts so a card grid can render without further fan-out. DIDs without a local profile record are hydrated from the public Bluesky AppView.
- dev.cocore.account.listApiKeys query List every API key belonging to the authenticated account, most-recently-created first. The owning DID is derived from the credential presented (session cookie or `Authorization: Bearer cocore-...`); there is no way to list another account's keys. Secrets are never returned — see `apiKeyView`.
- dev.cocore.account.listFriendEdges query Every directed trust edge in the network (friender → subject), for the explorer's friend graph. A cheap, pure edge list with no handle/avatar hydration.
- dev.cocore.account.listIncomingFriends query Every `dev.cocore.account.friend` record whose subject equals the queried DID — "who has trusted me with work?". Newest first; frienders are hydrated to a handle via the public Bluesky AppView when no local profile exists.
- dev.cocore.account.listProfiles query List every indexed `dev.cocore.account.profile` record (capped at 500). Used to render display-name + avatar chips for the DIDs hosting machines.
- dev.cocore.account.profile record A user's cocore-side profile. Auto-provisioned at first sign-in from the user's Bluesky public profile (so they don't see an empty card on first visit), then editable from /account. Independent from any bsky.app profile — the user can change their cocore display name or avatar without affecting their bsky one. One record per DID; the upsert flow uses rkey=`self` to keep it that way.
- dev.cocore.account.revokeApiKey procedure Revoke one of the authenticated account's API keys. The key stops authenticating immediately, but the row is retained with `revokedAt` set so it stays visible in listApiKeys as a revoked key (audit trail). Use deleteApiKey to remove it entirely. Scoped to the caller's DID — you cannot revoke another account's key. Idempotent: revoking an already-revoked or unknown key returns `revoked: false`.
- dev.cocore.account.tokenGrant record Records that an exchange has issued its one-time signup token grant to a recipient DID. Written by the exchange to its own PDS on the first balance event for a given DID — receipt as either side, top-up, or admission check. Issued exactly once per (exchange, recipient) pair. A consumer reconstructing balances offline starts each DID at this grant amount; absence of a tokenGrant record means the DID has never interacted with the exchange.
- dev.cocore.account.tokenPatronage record Records a patronage rebate: a periodic distribution of treasury balance back to an active member in proportion to their patronage (consumer spending + provider earnings) during the rebate period. Written by the exchange to its own PDS when the distribution fires. One record per (recipient, period) pair — the exchange MUST NOT distribute twice for the same (recipient, period). Direct analog of REI's annual member dividend or a credit union's quarterly capital credit: every term is visible, the ma
- dev.cocore.compute.attestation record A snapshot of a provider machine's hardware and software state, signed by its Secure Enclave. Content-addressed: many receipts strong-ref the same attestation record until the underlying state changes (binary upgrade, OS update, key rotation).
- dev.cocore.compute.defs defs Shared type definitions for dev.cocore.compute.* records.
- dev.cocore.compute.dispute record An exchange-signed adjudication of a complaint about a settled receipt. Published in the exchange's repo. The exchange's DID is the only DID permitted to publish a record at this NSID for a given settlement; any record at this NSID outside the exchange's repo is invalid by construction. The dispute lifecycle is open->resolved (terminal); resolution carries the outcome the exchange has already enacted (e.g. a refund settlement) and a signed rationale. Verifiers reading a settlement see status=dis
- dev.cocore.compute.exchangeAttestation record An exchange's self-published statement of operating posture: software commit, public signing key fingerprint, fee policy in effect, audit posture. The provider/requester analog of `dev.cocore.compute.attestation` for the exchange role. Settlements MAY strong-ref the active attestation so verifiers can pin which exchange-software / signing-key combination produced the record.
- dev.cocore.compute.exchangePolicy record An exchange's published terms of service. Records every parameter that affects how this exchange computes settlements and maintains per-DID token balances: fee schedule, supported currencies, self-loop rules, processor identifiers, and the token-accounting parameters (onboarding grant, balance floor, weekly refresh, monthly patronage distribution, treasury identity). A settlement record strong-refs the active policy so verifiers can re-derive the payout numbers offline. Policies are immutable pe
- dev.cocore.compute.job record A request for computational work. Published by the requester in their own repo before the work runs, so the provider has something to commit a receipt against.
- dev.cocore.compute.latency query Network latency rollup derived purely from indexed receipts' signed `startedAt`/`completedAt` pairs — the last ≤100 per group (overall, per-provider, per-model). No side metrics store: the receipts are the source of truth, so the numbers cannot drift from them.
- dev.cocore.compute.listJobs query Indexed `dev.cocore.compute.job` records authored by a requester (capped at 500). `requester` is required; omitting it returns no jobs.
- dev.cocore.compute.listProviders query List every indexed `dev.cocore.compute.provider` record (capped at 100). Read-only cache over the firehose; the provider's PDS is authoritative.
- dev.cocore.compute.listReceipts query Indexed `dev.cocore.compute.receipt` records (capped at 200), optionally filtered by provider DID, requester DID, and/or job URI.
- dev.cocore.compute.listSettlements query Indexed `dev.cocore.compute.settlement` records (capped at 200), optionally filtered by the settled receipt URI and/or the requester DID (matched against the authorization URI prefix).
- dev.cocore.compute.modelActivity query Aggregate receipt activity per model and per time window. Walks the most-recent indexed receipts (capped at 5000), groups by `body.model`, and tallies requests + tokens across the hour/day/week/month windows, with per-provider breakdowns. The scan cap is reported back as `scanned`/`scanLimit`/`truncated` so consumers can tell an exact total from a lower bound; `oldestScannedAt` is the earliest receipt that contributed to any window.
- dev.cocore.compute.paymentAuthorization record A requester's signed authorization permitting a named exchange to charge them up to a ceiling for a specific job. Published in the requester's repo before any work runs. Settlement records strong-ref this authorization to prove consent.
- dev.cocore.compute.provider record A compute provider's public profile. One record per physical machine. The DID owning the record is the provider's billable identity; the same DID may own multiple provider records (one per machine).
- dev.cocore.compute.receipt record A signed receipt of a single completed compute job. Published by the provider in its own repo. Strong-refs the requester's job and the active attestation. Carries an additional Secure-Enclave-bound signature so it remains verifiable across PDS migrations.
- dev.cocore.compute.settlement record An exchange's signed proof of payment for a receipt. Published by the exchange in its own repo. Strong-refs both the receipt being settled and the requester's payment authorization, so the full chain is independently verifiable.
- dev.cocore.compute.termsAcceptance record A user's affirmative acceptance of an exchange's terms of service / privacy policy. Published on the user's PDS so the record is portable + auditable + survives the user disconnecting from any one exchange. Clients prompt for re-acceptance whenever the active exchange policy's `termsVersion` doesn't match the version on the user's most recent acceptance for that exchange.
- dev.cocore.compute.verifyReceipt query Verify an indexed receipt offline-equivalently: structural checks against its job + attestation, a P-256 ECDSA signature check of `enclaveSignature` against the attestation public key, lexicon-schema validation, and — when an MDA cert chain is present — a hardware-attestation check bound to the signing key. `trustLevel` rises to `hardware-attested` only when a valid Apple chain certifies the receipt-signing key.
- dev.cocore.compute.verifySettlement query Verify an indexed settlement against its receipt and the requester's payment authorization: confirms the settlement chain is internally consistent and signed by the settling repo. Returns the verification verdict plus any findings.
- dev.cocore.devicePair.confirm procedure Approve or deny a pending device-pairing attempt, identified by the `userCode` the device displayed. Called from the verification UI by a signed-in user. Approving requires the provider `session` to grant to the device. When the requester supplied an allowlisted `returnUrl` at `start`, an approval echoes it back so the verification UI can send the browser there.
- dev.cocore.devicePair.describe query Describe a pending pairing attempt by its `userCode`, so the approve screen can say who is asking and for what. Public: it only echoes what the requester supplied at `start` (application name, key name, return URL) plus the attempt's status and remaining lifetime. It never returns the `deviceId` or a session.
- dev.cocore.devicePair.poll query Poll a device-pairing attempt by `deviceId`. While the user has not acted, returns `pending`. On approval, returns `session` together with the granted provider session. Terminal negative states are `denied`, `expired`, and `consumed`. An unknown `deviceId` is `unknown`.
- dev.cocore.devicePair.start procedure Begin a device-pairing flow (OAuth 2.0 device-authorization style). Returns a `deviceId` plus a short human-typable `userCode` and the `verificationUri` where a signed-in user approves the pairing. The caller then polls `dev.cocore.devicePair.poll` until approval. The optional input lets an application (rather than a provider machine) say who it is: `appName` is shown on the approve screen, `keyName` names the minted API key so the user can recognise and revoke it, and `returnUrl` is where the a
- dev.cocore.inference.dispatch procedure Submit an inference request and stream the result back as Server-Sent Events. Authenticates the requester, runs the dispatch core, and emits typed SSE frames. Unlike `submit` (which returns URIs to poll), `dispatch` drives the full request and streams plaintext output chunks until completion. Confidentiality: by default the AppView seals the prompt to the chosen provider on the caller's behalf (`best-effort` tier) — convenient, but the AppView is in the plaintext path. A caller that needs priva
- dev.cocore.inference.status query Poll for the outcome of a submitted job. Returns `pending` until a matching receipt is indexed, `received` once the receipt lands, and `settled` once a settlement also lands. Receipt and settlement are returned as indexed records when present.
- dev.cocore.inference.submit procedure Submit an inference request for the authenticated requester. Builds a (paymentAuthorization, job) pair scoped to the configured exchange, publishes both to the requester's PDS, and returns the job/authorization URIs so the caller can poll for a receipt via `dev.cocore.inference.status`.