dan @danabra.mov@bsky.brid.gy
Public

i think is a beneficial exercise for anyone who writes technical content to read the left version and the right version and to think why they're essentially saying the same thing but one of them is a million times easier to follow. how did that happen?

Lexicon Resolution requires 2 things, control of the domain which the Lexicon's NSID refer to (e.g. bookhive.buzz in the example above), and for the Lexicon to be published in some account's PDS (where your account data is stored in ATProto). The process of Lexicon resolution is actually pretty simple: Given a Lexicon NSID (buzz.bookhive.defs), remove the name part, to derive the Domain authority (which was in reverse-DNS notation). So, we'd end up with bookhive.buzz Look for a DNS TXT record at _lexicon.<domain authority>, just like handle resolution, which should have published did=<account did> to point to the account which holds the Lexicon schemas. So, at _lexicon.bookhive.buzz there is a TXT record that stores did=did:plc:enu2j5xjlqsjaylv3du4myh4 (which is the did of the @bookhive.buzz account) In the account's PDS, there should be a collection com.atproto.lexicon.schema which stores the schema's NSID as the record key (rkey) and the value is the Lexicon schema with "$type": "com.atproto.lexicon.schema", "lexicon": 1 added to the schema object. So, at at://did:plc:enu2j5xjlqsjaylv3du4myh4/com.atproto.lexicon.schema/buzz.bookhive.defs it will contain the Lexicon schema:Lexicon schemas are published publicly as records in atproto repositories, using the com.atproto.lexicon.schema type. The domain name authority for NSIDs to specific atproto repositories (identified by DID is linked by a DNS TXT record (_lexicon), similar to but distinct from the handle resolution system. The com.atproto.lexicon.schema Lexicon itself is very minimal: it only requires the lexicon integer field, which must be 1 for this version of the Lexicon language. In practice, same fields as Lexicon Files should be included, along with $type. The record key is the NSID of the schema. A summary of record fields: $type: must be com.atproto.lexicon.schema (as with all atproto records) lexicon: integer, indicates the overall version of the Lexicon (currently 1) id: the NSID of this Lexicon. Must be a simple NSID (no fragment), and must match the record key defs: the schema definitions themselves, as a map-of-objects. Names should not include a # prefix. description: optional description of the overall schema; though descriptions are best included on individual defs, not the overall schema. The com.atproto.lexicon.schema meta-schema is somewhat unlike other Lexicons, in that it is defined and governed as part of the protocol. Future versions of the language and protocol might not follow the evolution rules. It is an intentional decision to not express the Lexicon schema language itself recursively, using the schema language. Authority for NSID namespaces is done at the "group" level, meaning that all NSIDs which differ only by the final "name" part are all published in the same repository. Lexicon resolution of NSIDs is not hierarchical: DNS TXT records must be created for each authority section, and resolvers should not recurse up or down the DNS hierarchy looking for TXT records.
0
0
0

If you have a fediverse account, you can quote this note from your own instance. Search https://bsky.brid.gy/convert/ap/at://did:plc:fpruhuo22xkm5o7ttr2ktxdo/app.bsky.feed.post/3mao7r7tfys2n on your instance and quote it. (Note that quoting is not supported in Mastodon.)