Scope policy for non-Bluesky AT Protocol service wrappers

[KC-2001MS]

This is about ATProtoKit's stance on supporting non-Bluesky AT Protocol services (Whitewind, Frontpage, Streamplace, Smoke Signal, Tangled, etc.) at the API method / convenience record layer (the equivalent of AppBskyAPI and ATProtoBlueskyAPI for those services) — not the lexicon / type-generation layer already discussed in #191.

Context

In my own app I currently maintain per-service extension files on top of ATProtoKit as a stopgap. As the AT Protocol ecosystem keeps growing, pulling every third-party service into ATProtoKit itself would obviously bloat the library — binary size, build time, lexicon maintenance, DocC surface, etc.

So before deciding what to keep app-local vs. propose upstream, I'd like to understand where the line is currently drawn.

Question

Which direction is closest to the current thinking?

1. Bluesky-only core (manual) — ATProtoKit stays "a Swift client for AtProto core + Bsky lexicons". The existing AppBskyAPI / ChatBskyAPI / ATProtoBlueskyAPI namespaces are the boundary; other services are out of scope and belong in consumer apps or third-party packages.
2. Optional subpackages in this repo — e.g. ATProtoKitWhitewind, ATProtoKitFrontpage shipped as separate SwiftPM products from this repo, opt-in, each adding its own ComWhtwndAPI / FyiUnravelFrontpageAPI namespace.
3. Generator emits types only — the planned lexicon generator (Separate packages for AtProto and Bsky Lexicons #191) covers type definitions; per-service Method / Record files stay out of scope and are consumer-side.
4. Generator emits types + API methods — the generator emits both Swift types and the per-method API call files (the equivalent of AppBskyFeedGetTimelineMethod.swift) from lexicon JSON, so ATProtoKit ships the tool rather than per-service code.
5. Undecided / case-by-case.

Not asking for any specific service to be added — just trying to understand the scope policy.

[MasterJ93]

The direction that ATProtoKit will eventually go is that the lexicon generator will generate the Swift models and methods, which includes all of the ones from Bluesky. I'm leaning on the idea that all of the lexicons will not be built into ATProtoKit, and, instead, will be something that developers can implement themselves. The goal is to simply have developers use the Terminal to go into the folder, dump the lexicons into their project, and just simply type:

atlexiconc build

in the Terminal.

That's the eventual goal. However, this will be a bit difficult to achieve, so I'm going at this slow and in stages. ATlexiconC is a separate Swift package entirely, and will include the library and CLI, so if desired, the developer can put it in their dependencies. Just be mindful that ATLexiconC itself will most likely have a number of dependencies attached to it, so if this is something that makes you uncomfortable, please keep that in mind, and you would be better off with simply using the CLI. I think a dedicated macOS app for those that prefers a GUI could work as well, but not until I've completed enough of ATLexiconC.

As for the timeline for ATLexiconC, this is going to be a summer project, so it may take a little bit of time before a workable version that developers can reliably use will be available. But once it reaches that point, the generated code will slowly be replacing the hand-written code that's in ATProtoKit right now. And then eventually, once I've progressed the package even further, I will eventually remove them in favour of having developers make the generator build the lexicons themselves. However, I still would like to find a way for developers to "plug and play," so some of the CLI commands could possibly include the ability to build a bunch of Bluesky-specific lexicons, as well as well-known lexicons, such as WhiteWind, Frontpage, and others.

But at the moment, as a stopgap, I recommend that you temporarily fork ATProtoKit and manually add the lexicons you desire itself. Once I'm ready, however, you shouldn't need to do that. In any case, I'm hoping that, before Autumn arrives, ATLexiconC will be ready for you. It's just a bit complicated because I want to ensure that, by default, developers don't have to worry too much about manually tweaking so many things. I don't want to rush this: I want to make something that you feel comfortable using and that gives you the least amount of headaches possible.

Hopefully that answers your question, but let me know if there's anything that's confusing or unclear.

[KC-2001MS]

Thanks, that's clear. Knowing ATLexiconC is the long-term home, I'll keep the third-party services (WhiteWind, Frontpage, etc.) as my own app-side extensions for now and focus my upstream contributions on improving the Bluesky side instead. No rush on the timeline.