Lexicon Garden

dev.cocore.app.registration

How an application announces itself to co/core so it can connect users' accounts with one click ("Sign in with co/core"). Published by the application on ITS OWN account (a did:plc or did:web with a repo), one record per DID at rkey `self` — there is no central app registry. When the app calls `dev.cocore.devicePair.start` with `appDid`, the AppView reads this record from the app's PDS: `name` is what the approve screen shows, and `returnUrls` are the only places the approve screen may send the browser afterwards. A return URL is additionally honoured only when its host proves it belongs to this DID by serving `https://<host>/.well-known/cocore-app.json` containing `{"did": "<this DID>"}` — so a record on a stranger's account cannot borrow a real app's domain.

Repository @cocore.dev did:plc:5quuhkmwe2q4k3azfsgg7kdz not from the namespace authority
Details · record, key literal:self
Kindrecord
Record keyliteral:self
Authorityapp.cocore.dev
Indexed
Compare Edit in builder → Fork →

Record

record · key literal:self

Properties

createdAt

requiredstring · datetime

description

string

One sentence on what the app does with the connection. Plain text.

  • maxLength: 300

iconUrl

string · uri

Square icon, https. Optional.

  • maxLength: 2048

name

requiredstring

Human name of the application, shown on the approve screen.

  • maxLength: 40

returnUrls

requiredarray

Where the approve screen may send the browser after approval. https only. A requested return URL must match one of these on origin and path (its query string may differ).

  • maxLength: 10
itemsstring · uri
  • maxLength: 2048

updatedAt

string · datetime

website

string · uri

The app's home page, linked from the approve screen.

  • maxLength: 2048

Similar lexicons

semantic match

Lexicons whose schemas describe something close to this one. Check them before publishing a new one that overlaps.

  • 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

  • community.lexicon.app.entry

    record

    A third-party or community listing for an app built on or for the AT Protocol.