Draft
In desktop computing, the filesystem is undoubtedly the most important source of agency that end-users experience because it facilitated the separation between data and the apps that operate on that data. As @orionreed.com goes on to write:
In the era of personal computing — which itself broke from the terminal-and-mainframe model, where user work lived on institutional machines and was accessed through centrally administered interfaces — the file was a relatively autonomous object, existing separately from the application that produced it. The practice of format openness was always contested; opaque formats were common from the beginning. But the file as portable possession was a powerful norm, embedded in operating systems, programming languages, and user expectations alike. The Unix tradition, in particular, cultivated what McIlroy, Pinson, and Tague described as a preference for programs that handled "streams of text" as a universal interface, reinforcing the notion that data should be legible and movable independently of the tools that operated on it.
Even in a world of an growing amount of proprietary desktop apps and files types, the filesystem was a refuge for data to rest outside the control of corporations. But, as @orionreed.com elaborates, over time the digital topology of desktop computing slowly changed as corporations started to enclose their software and computers started connecting to the internet; the agency the file once had was sucked up by corporately-control applications.
Well this is why I've always been found the idea of atproto being a social filesystem quite provocative (in fact I may have nudged @danabra.mov to write that piece). I find it quite helpful to frame atproto as a data, identity, and distribution substrate for the web,
In a post-app ecosystem like the atmosphere, there is no single social media platform that controls access to data or the user interfaces that we use to interact with that data. One challenge that arises in such an open ecosystem is that you can't easily know if a given web page canonically represents an AT record and, if so, what that record is.
Most web pages that directly map to an AT record do not directly include the full AT URI in the URL, they opt for a cleaner version. For example, here's a Bluesky link that refers to its canonical AT record.
https://bsky.app/profile/did:plc:zcanytzlaumjwgaopolw6wes/post/3mogapsjyg225
↓
at://did:plc:zcanytzlaumjwgaopolw6wes/app.bsky.feed.post/3mogapsjyg225There is nothing on the bluesky web page that indicates that it represents a canonical AT record. While it might be easy to parse the AT record from this URL this doesn't scale for an open-ended set of apps all with different URL structures that can also be changed at any time. This means that projects like @aturi.to have to manually hardcode how to parse the AT record to/from URLs from a closed set of web pages. One downstream effect of this is that these kinds of projects are likely to work with the most popular web pages, that may perpetuate the kinds of network effects they are simultaneously trying to mitigate. It doesn't seem possible for this to scale without the author of the web page being able to include this mapping themself.
How has this showed up?
This is not a new challenge in the atmosphere, standard.site has already been using <link> tags so a web page representing a standard.site document could be mapped and verified back to their AT record. Standard site asks that publishes add two tags the their web pages:
<link rel="site.standard.publication" href="at://did:plc:abc123/site.standard.publication/rkey" /> <link rel="site.standard.document" href="at://did:plc:xyz789/site.standard.document/rkey" />
One of the things this enables is that standard.site records and web pages displaying that publication can be bidirectionally verified. Additionally, projects like @standard-reader.app can create web extension experiences that let readers recommend and subscribe to to publications without needing to log into that actual web page.
Unfortunately, @rich-harris.dev pointed out that this produces invalid HTML because AT URI's are not valid URLs. This means that there is a small moment in time, where we might need to make a breaking change to standard.site, likely moving to <meta> tags. I hope we can use this opportunity to generalize these tags to work with any AT record and potentially mapping other parts of atproto.
There are also closely adjacent discussions and explorations that have popped up around app lexicons (see here and here), lexicons for describing URL structure, and mapping DOM elements to AT records. I see this explorations as adjacent, yet distinct. Many web pages that reference a AT record likely also contain in their DOM other AT records. There are benefits to having a community lexicon for what apps exist and maybe what their URL structure is, but not every atproto-augmented web page is an app or should be required to participate in contributing metadata in that manner.
What now?
The community is still working through what this looks like, Although the web has existing ways to link the canonical URL or author, I personally feel that following in the steps (and success) of open graph and using <meta> tags provide us a better path forward with extending the language of the existing web. Currently it's looking something in the realm of this.
<meta property="at:uri" content="at://…" /> <meta property="at:did" content="did:…" />
@bmann.ca suggested that a meta tag for dids could be used for someone to claim the authorship of a web page even if it doesn't map to a canonical AT record. @orta.io's keytrace.dev could act and a really interesting app-agnostic verifier for these kinds of situations.
If you have thoughts or ideas now is the time join this conversation here. We hope that we can come to consensus so that @standard.site and the tooling around it can move forward with this breaking change. Then it's about working with different apps and websites to adopt this for and AT records they have. The way verification incentives
deduplicate
links are more social because people can be pinged
lowers the barrier to partake in the ecosystem
semble will tak