Hi @rothgar, the blog post discusses additional Lexicons in the "New Application Development" section.

That section mentions new lexicons aren't available yet but I was mostly curious if changes such as auth and BGS will affect people trying to create new applications with AT and PDS instances.

Is there a generic PDS implementation that provides no built-in lexicons? Would it be possible to build a PDS with static files?

In general, PDSes aren't [supposed to be] lexicon-specific. The current official PDS limits itself to the official app.bsky lexicons, but that's the team's policy choice for that PDS, not an inherent part of the protocol or design.

Here are a couple independent PDS implementations that afaik are both lexicon-agnostic:

• https://github.com/snarfed/arroba
• https://github.com/DavidBuchanan314/picopds

Changes to auth could impact the entire ecosystem and all apps/clients, though if lucky they may be backwards-compatible not require any immediate code changes. Still planning that out.

The BGS change would require any other AppViews for other Lexicons to switch config to point at the BGS (instead of just the one PDS), but otherwise no change needed.

Would it be possible to build a PDS with static files?

If you mean a PDS with no code running, we mention in the blog post an idea related to that on the backburner, which is being able to host repositories as just a static .car file, and sending a webhook-like request to the BGS (or many/"all" BGS instances) to re-crawl when there is a change. That concept is on the back burner, no timeline.

Is there a generic PDS implementation that provides no built-in lexicons?

As @snarfed mentions, it should be possible to do a totally Lexicon-agnostic PDS instance.

I would split hairs a bit more and say we hope that most PDS implementations will end up compile-time agnostic, but be able to validate Lexicons at run-time. That means being able to "resolve" (download and cache) unknown Lexicons, based on the NSID, and then validate records against the Lexicon schema file. Or, if downloading from the live web is scary, have a local folder with a bunch of lexicon files which can be updated/expanded without re-building/re-compiling/re-codegen the PDS code. The specific behavior this enables is doing record validation when validate=true (the default) at record creation time. This could always be overridden by setting validate=false (though there are some to-be-specified other data model validations which should always be enforced, like only allowing string keys in maps/objects).