So OK I keep trying to like #atproto / #bsky, lexicons specifically but they make it so hard. like... let's see, OK we're going to reinvent RDF and JSON-Schema such that
- schemas are identified by [reverse domain names](https://atproto.com/specs/nsid) like `com.example.myLexicon`
- there is some concept of a ["namespace authority"](https://atproto.com/specs/lexicon#authority-and-control) rooted in DNS ownership of a domain name that is supposed to maintain a set of lexicons and do things like make sure there are no duplicates (eg. lexicon IDs are case sensitive but you are not allowed to have IDs that differ only in case, which a ns authority has to ensure)
- but there is no means of *using* the domain to retrieve a schema, so eg. it is explicitly *not* spec'd to require `com.example.myLexicon` be at `myLexicon.example.com` - so the whole goofy Javabrained reverse-domain name thing as the ID is pointless
- Accordingly, lexicons have to be sourced ad-hoc and by convention, and the convention is bonkers!!!! According to their reference implementations, the way you are supposed to use lexicons is to autogenerate their json schema definitions and version them locally everywhere they are used. I can't express how baffling this is to me - like the `atproto` monorepo has a top level [lexicons](https://github.com/bluesky-social/atproto/tree/main/lexicons) directory, and then their [Makefile](https://github.com/bluesky-social/atproto/blob/de2dbc2903a383f092756d3d2ad1ff3753361e76/Makefile#L29-L36) then goes through several of the subpackages calling each of their (separate) code generation [scripts](https://github.com/bluesky-social/atproto/blob/de2dbc2903a383f092756d3d2ad1ff3753361e76/packages/api/package.json#L23), resulting in local, vendored copies of each of the lexicons - and by copies of the lexicons i mean both [generated code](https://github.com/bluesky-social/atproto/tree/main/packages/api/src/client/types) AND [typescript interfaces](https://github.com/bluesky-social/atproto/blob/main/packages/api/src/client/types/app/bsky/feed/defs.ts) AND an entire copy of the whole [schema](https://github.com/bluesky-social/atproto/blob/main/packages/api/src/client/lexicons.ts).
- This is presumably because there are REFERENCES between lexicons EVEN WITHOUT those lexicons having a meaningful notion of location or dereferenceability - how would you know what `'app.bsky.feed.defs'` is referring to unless you *packaged and built all lexicons together*? the [method for resolving references](https://github.com/bluesky-social/atproto/blob/de2dbc2903a383f092756d3d2ad1ff3753361e76/packages/lexicon/src/lexicons.ts#L212) literally requires them to all be locally present at runtime as far as i can tell, idk the lexicon code is unreadable to me.
- There is no means of versioning, so "Once a schema is published, it can never change its constraints" and the only means of changing is to change its freaking name, so `com.example.myLexicon.FinalFinalv2` is explicitly encouraged. The reference implementations repeatedly violate this, though, so whatever.
- Again, there is no actual mechanism of "publishing" a schema, though, so it's completely unclear what that's supposed to mean - how do people know the schema has changed names since they just have it hardcoded in their clients?
and the entire spec documentation is just a bunch of harebrained ideas that amount to, as far as i can tell, just literally being JSON-Schema just different? And they compare it to RDF but there's literally nothing to compare there except for the absence of an explanation as to why they didn't just use JSON-LD. I literally cannot tell how this is supposed to work as an interoperability/extensibility layer if there is no means of resolving terms or lexicons and all definitions have to be known in advance.
jonny
All GNU social JP content and data are available under the