Protocol Roadmap Discussion

[bnewbold]

This is a place for comments and discussion on our protocol roadmap blog post: https://atproto.com/blog/2023-protocol-roadmap

There is a separate dedicated topic tracking upcoming and in-progress changes with more granularity:
#1711

[rothgar]

Do any of these infrastructure, PDS, and protocol changes affect new lexicons/services from adopting AT protocol?

All of the examples are Bluesky focused since it's the application using any of the technology

[bnewbold]

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

[rothgar]

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?

[snarfed]

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

[bnewbold]

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).

[camelusminimus]

If I may leave my thoughts at this place about the "further ahead" part of the Roadmap, esp. the section on DMs.

While the described long-term goals are laudable in my opinion (and I tip my hat to whoever is capable of squaring that circle), I would like to ask if this plan originates more from a desire for feature parity than from trying to fulfill a specific need of the users.

I am not trying to appear more of an expert than I am (I only dabbled in HCI in my studies). Still, as I see it, the wish for DMs mainly originates in wanting to selectively provide people the ability to start an out-of-timeline conversation.

Would it, perhaps, be more uncomplicated to integrate a means to (automatically) provide specific others (followers/mutuals/whatever) with a handle to another communications channel? (Perhaps an email address?)

This might be, well probably is, a ridiculous solution, and not possible to reliably integrate into the protocol, of which details I am more ignorant than I wish. My main goal behind writing this potential nonsense is to ask if the need behind the request for DMs could not be, maybe as a less complex interim solution, integrated differently.

Thank you for reading my ramblings, and your work on the protocol.