In part 1 of this series, I laid out a the unrealized story of interop that linking could afford in the Atmosphere and a community proposal to standardize <meta> tags to solve this. The proposal is about ready to become stable at 1.0, although there will be one last round of feedback. Since then the ecosystem started quickly start adopting it, including bluesky-social/social-app. One proxy for its adoption is that more than to 20% of the links saved to now have an AT URI that can be scraped.

But the work is not done, half of the problem is still unsolved – mainly given an AT URI how would you get a URL to view and interact with that data? Should records always have a canonical URL? How might end-users declare their preference for how to view/interact with certain content? To 's question, how do we establish trust in this process? The reality we are stuck with right now is that most apps have to hardcode "open in bluesky", further reinforcing networks effects of app adoption, like I mentioned in part 1.

It's worth noting that similar challenges exist with desktop file system and apps – an open-end ecosystem of apps operating over a shared set of files. The biggest difference is that this happens on a device-by-device accord, and so the operating system and the browser have become the layer where these challenges are answered. In the atmosphere, there currently doesn't exist a layer similar to the operating system, browser, or PDS as a user-agent, where we could encode this behavior for end-users, and that puts us at an disadvantage for how end-users experience the network.

Although the community is exploring what this layer could look like1, for now, end-users experience the network though a disparate set of (web) apps with little interoperable serendipity in this regard. We need consensus on to facilitate opening AT URIs across apps and, eventually, in a way that works with a OS/browser layer.

Breaking down the problem space

There have been multiple people exploring how this could work:

  • The Community App Working Group has formalized a lexicon for apps to declare themselves. As part of that there is a optional field for apps to declare the lexicons they consume/produce.

  • 's deep links proposal suggests a lexicon where apps can declare how AT URIs are encoded in their URLs.

  • encodes the canonical URL directly into the lexicon so it could be bidirectionally verified.

  • and have discussed a sidecar/inline field to declare canonical/alternative URLs.

  • walks through a couple solutions as well.

The deep links proposal is a lexicon that, in my opinion, goes against the principle that the PDS is a minimal source of truth. The source of truth for an app's routes is it's code base and requiring every app to publish their routes to the PDSon every deploy is impractical to extract from code bases and I don't think it will not scale in a open, permissionless ecosystem.

In the desktop file system, where data is functionally separated from apps there are no canonical apps, although the OS might provide default ones for common file types. Similarly, atproto functionally separates accounts (and their data) from apps, an along the same line of thinking, there is usually no canonical URL for a given record. standard.site is the exception here, where the end-user is declaring the canonical URL for their long form writing.

The proposal for URL sidecars (regardless of if it's a separate record or inline) attempts to generalize this for any record. My main gripe is that per record provenance is overkill and needing an additional sidecar or adversarially extending every record would be a massive burden on the network. I suggest we treat this as a edge case, handled lexicon by lexicon basis.

I think 's suggestion of letting the lexicon decide the canonical URL was nifty on first thought, but ultimately centralizes the governance of this decision to en entity that already controls the lexicon. I'd like to see more plurality around governance of opening AT URIs. I think letting the lexicon decide will incentive less collaboration and interop in the ecosystem.

The proposal

I think we should aim to minimize the burden of interoping (e.g. how often does an app update the the agreed upon interface) and the surface area exposed by each app (e.g. routes vs lexicons). Focusing on how apps interact with lexicons feels like the right balance here:

  1. 1.

    If an apps wants to partake in this interop they can declare (and keep up to date) a community.lexicon.app.entry lexicon, including the base URL for their website and the lexicon that they consume and produce.2 Additionally, the specified URL must accept a query param of ?at-uri=<AT URI> and redirect that AT URI to it's corresponding URL (or a 404).

  2. 2.

    A standardized XRPC endpoint, community.lexicon.app.getList, that given a lexicon and a read/write flag that returns a list apps that consume/produce that record, sourced from community.lexicon.app.entry.

    • It feels like trust is established at this index. Indexes could use verification records, reviews, rating, etc. to establish trust about what apps to recommend.

    • This could be an interesting use case where the PDS proxying could be helpful. The PDS intercepts the request for a list of apps and returns the user's preference instead. If no preference exists, it fallbacks to the index's response.

  3. 3.

    A standardized community.lexicon.app.userPreference lexicon that lets a end-user declare what apps they prefer to use. It's a backlink to community.lexicon.app.entry.

  4. 4.

    A standardized XRPC endpoint, community.lexicon.app.getUserList, given a lexicon and a read/write flag returns a list apps that consume/produce that record that the user has opted in to.

Open questions

  • Usually app defaults are managed by a trusted layer like the OS/browser. The PDS is a consensual surface, meaning if a end-user unintentionally gives an app permission they could change all of an end-users defaults. It also unclear to me if these settings should not be publicly viewable atproto space or only editable from the PDS?

  • The proposal is indifferent about whether apps should generate an app picker or pick an app itself. That's consensus that can emerge on top.

  • Could this system work with web tiles, as well? Just that the app loads a web tile in place instead of redirect to another app?

  • If there are no apps for a lexicon do we fallback to a record explorer like ?

If you have thoughts and feedback please partake in the discussion happening here or here.