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 like com.example.myLexicon
there is some concept of a "namespace authority" 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 directory, and then their Makefile then goes through several of the subpackages calling each of their (separate) code generation scripts, resulting in local, vendored copies of each of the lexicons - and by copies of the lexicons i mean both generated code AND typescript interfaces AND an entire copy of the whole schema.
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 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.
like wouldn't it be cool if we had this interoperability layer where if you have all of it in advance and it is in the format you expect and you build your program around expecting it to be there and unchanged and unrelated to the other versions of what is ostensibly the same thing. we could call it "code." I think there might be some important things missing in this here schema language/subprotocol thingamajig
what does that even mean, are they going to use the BGS to just not serve some accounts, or how are they going to enforce account ratelimiting on the whole network once they enable federation on their servers. smoke and mirrors my dogs
https://github.com/bluesky-social/atproto/discussions/1711
@jonny@neuromatch.social oh boy, no way this could be abused to maintain overall control of a 'federated' network.