Proposal: Lexicon schema resolution lexicon #48
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,21 @@ | ||
| { | ||
| "lexicon": 1, | ||
| "id": "community.lexicon.schema.defs", | ||
| "defs": { | ||
| "schemaView": { | ||
| "type": "object", | ||
| "required": ["uri", "cid", "record", "indexedAt", "dependencies"], | ||
| "properties": { | ||
| "uri": { "type": "string", "format": "at-uri" }, | ||
| "cid": { "type": "string", "format": "cid" }, | ||
| "record": { "type": "unknown" }, | ||
| "indexedAt": { "type": "string", "format": "datetime" }, | ||
| "dependencies": { | ||
| "type": "array", | ||
| "description": "List of direct dependencies of this schema. These are the external refs used within the record.", | ||
| "items": { "type": "ref", "ref": "com.atproto.repo.strongRef" } | ||
| } | ||
| } | ||
| } | ||
| } | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,48 @@ | ||
| { | ||
| "lexicon": 1, | ||
| "id": "community.lexicon.schema.getSchemas", | ||
| "defs": { | ||
| "main": { | ||
| "type": "procedure", | ||
|
There was a problem hiding this comment. Should this be a 
Member
Author
There was a problem hiding this comment. I meant to leave a comment about this. It's not really possible to express the input as parameters without inventing some new string format that's like I'd prefer not to do that invention here (it should be an atproto core spec) but also stuffing those kinds of strings into the query string would reduce the amount of lexicons this endpoint could return I think (because of URL length limits of many systems and tooling). There was a problem hiding this comment. I'm not sure there needs to be any inventing here. Lexicon retrieval is more or less a https://github.com/bluesky-social/atproto/blob/main/lexicons/com/atproto/repo/getRecord.json
Member
Author
There was a problem hiding this comment. This endpoint returns multiple lexicons, not a single one. It's closer in spirit to app.bsky.feed.getPosts than it is to getRecord.
Member
Author
There was a problem hiding this comment. There's literally no way to encode a "list of at URIs with optional CIDs" without inventing a new string format. |
||
| "description": "Gets schema views for a specified list of lexicon schemas (by AT-URI, with optional CID).", | ||
| "input": { | ||
| "encoding": "application/json", | ||
| "schema": { | ||
| "type": "object", | ||
| "required": ["refs"], | ||
| "properties": { | ||
| "refs": { | ||
| "type": "array", | ||
| "description": "List of schema refs (AT-URI with optional CID) to return hydrated views for.", | ||
|
Member
Author
There was a problem hiding this comment. It would be nice to encode this type of "at uri with optional cid" as a shared type as I think it's probably valuable in many use cases. Naming is hard tho,
Member
Author
There was a problem hiding this comment. It might be strong tho if the CID is included! Sometimes it's weak, sometimes it's strong |
||
| "items": { | ||
| "type": "object", | ||
| "required": ["uri"], | ||
| "properties": { | ||
| "uri": { "type": "string", "format": "at-uri" }, | ||
| "cid": { "type": "string", "format": "cid" } | ||
| } | ||
| }, | ||
| "maxLength": 25 | ||
| } | ||
| } | ||
| } | ||
| }, | ||
| "output": { | ||
| "encoding": "application/json", | ||
| "schema": { | ||
| "type": "object", | ||
| "required": ["schemas"], | ||
| "properties": { | ||
| "schemas": { | ||
| "type": "array", | ||
| "items": { | ||
| "type": "ref", | ||
| "ref": "community.lexicon.schema.defs#schemaView" | ||
| } | ||
| } | ||
| } | ||
| } | ||
| } | ||
| } | ||
| } | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dependency strong refs are returned so that a package manager could resolve a point-in-time snapshot of the lexicon tree. Discussion about that here.
The actual CID that the appview returns would be implementation specific and so could either return the CIDs at the time the parent was indexed, the latest CIDs regardless of parent CID that was requested, or something else.