Separate packages for AtProto and Bsky Lexicons

[mcprostar205]

There are use-cases where custom lexicons will need to use definitions from other lexicon packages as standard building blocks. For instance, BlobReference and ReplyReference are good candidates to re-use within custom lexicons. However, both do not have initializer functions in the AtProtoKit and Swift extensions are barred from introducing initializers to another package's public types. With an AtProtoKit hat on for only managing AtProto and Bsky lexicons, this might make sense as the package encapsulates the creation of these internally. But, that limits customization or extensions to lexicons and the use of the kit for those lexicons. The only option is to clone them and any references that may include them and be reusable. If these lexicons were in separate packages with all initializers, components of these lexicons would be more reusable. Would be curious to hear your perspective on making components of these lexicons re-usable within custom lexicons.

[MasterJ93]

With respect to the lack of initializers on BlobReference and ReplyReference, all lexicon models in ATProtoKit are supposed to have proper public initializers, not just the default ones for decoding. For reference, some models already have them. The reason others don't is the overhead: keeping initializers in sync with evolving lexicons is a ton of manual work, especially since lexicon specs can change frequently. That said, I welcome PRs adding initializers to existing models (like BlobReference/ReplyReference); if you submit one, I’ll happily review and merge.

With respect to modularity, it's a goal I've been trying to work on. There’s ongoing work (example: #181) to reduce duplicate code and make components more reusable. Furthermore, ATProtoKitConfiguration is supposed to help with your use case, though I understand it's not enough (work has been slow on that front and a couple of things are probably outdated at this point). I'm undecided on making a separate lexicon package, but it doesn't seem like something I'm fully comfortable with: if you've noticed, I've added documentation to all of the lexicon models and methods, and separating them into different DocCs would be frustrating to me without any form of help, with plans on adding much more detail on all documentation in the lexicons.

A lexicon generator will go a long way into fixing your pain points. However, building this generator is non-trivial. I want it to produce Swift code that’s properly readable and fits with the API Design Guidelines and I don't want to be lazy with this. I’m leveraging Apple’s OpenAPI generator for part of this, but it’s not a complete solution; some lexicons don’t map cleanly to Codable types and require custom methods, like enforcing character/array length constraints or special date handling. The OpenAPI generator doesn’t handle all the edge cases or nuances present in the official lexicon JSON (for example, my models trim extra items instead of failing with an error). Realistically, getting this right to the point where it would work and I can release it properly will take all summer.

---

Just to be transparent: ATProtoKit is a large and evolving project, and I’m only one person. My personal energy and bandwidth do have an impact on how quickly things move and what gets prioritized. Suggestions sometimes fall through the cracks, but it’s not intentional. Your feedback is valuable, and I’m always looking for feedback and considering them, even if I can’t act on everything immediately.

TL;DR:

• I'm aware of the lack of public initializers for most models and that needs to be fixed.
• I'm fine with PRs for the above.
• I'm also okay with PRs to help with modularity.
• I've not decided with a separate lexicon package, but I'm not exactly thrilled with making them separate since it means maintaining separate DocCs.
• Modularity is being improved, but progress is slow.
• A lexicon generator is being developed to address pain points, but it’s complex and will take time to complete.

[mcprostar205]

Your efforts bringing ATProtoKit to the Swift community is very appreciated. It's a massive effort encompassing the breadth of AtProto and Bluesky apis. I'm more than happy to help improve this package to bring it closer to a solid 1.0 version. I'll open a PR for this specific item to improve the lexicon initializers mentioned. Thank you!