At this level
dev.cocore.account · 14- 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