dev.cocore.account.friend

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 (friender, subject). The friends-only chat-completions endpoint reads these records to constrain the advisor's pickFor candidate set.

Repository @cocore.dev did:plc:5quuhkmwe2q4k3azfsgg7kdz namespace authority
Details · record, key tid
Kindrecord
Record keytid
Authorityaccount.cocore.dev
Indexed
cid bafyreidk7aklcgo62nq7awaewdgxblna6thk2vpltxpgwsvuajtsn2d7me

Checks

Valid
  • missing-primary-description defs.mainThe record has no description.
JSONDownload
{
  "$type": "com.atproto.lexicon.schema",
  "defs": {
    "main": {
      "key": "tid",
      "record": {
        "properties": {
          "createdAt": {
            "format": "datetime",
            "type": "string"
          },
          "note": {
            "description": "Optional free-form note the friender attaches to remind themselves who this DID is or why they trusted them. Plain text; never shown to the subject — this is the friender's own private label.",
            "maxLength": 1024,
            "type": "string"
          },
          "subject": {
            "description": "The DID the friender is extending trust to. MUST be a syntactically-valid DID (did:plc:… or did:web:…). Resolved-to-handle at write time but the DID is the authoritative identifier — a subject who later changes their handle is still the same friend.",
            "format": "did",
            "type": "string"
          },
          "subjectHandle": {
            "description": "Display-only mirror of the subject's bsky handle at friend-time. Captured so dashboards can render `@handle` without paying a PLC round-trip for every friend on every page load. Authoritative handle resolution still goes through PLC; a stale value here is OK.",
            "maxLength": 256,
            "type": "string"
          }
        },
        "required": [
          "subject",
          "createdAt"
        ],
        "type": "object"
      },
      "type": "record"
    }
  },
  "description": "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 (friender, subject). The friends-only chat-completions endpoint reads these records to constrain the advisor's pickFor candidate set.",
  "id": "dev.cocore.account.friend",
  "lexicon": 1
}