{
  "$type": "site.standard.document",
  "canonicalUrl": "https://ayc0.dev/posts/standard-site",
  "description": "This post is a brief introduction to the AT Protocol, standard.site, and how to connect a website to it",
  "path": "/posts/standard-site",
  "publishedAt": "2026-06-19T00:00:00.000Z",
  "site": "at://did:plc:wifmfjqoxnruni5h62e6zp2y/site.standard.publication/3mn6dj35act2i",
  "textContent": "What is standard.site?\n\nImagine you have your own blog. You’d love to notify readers when you publish something new, or have your posts show up in a unified search. Your first instinct might be to host on platforms like Medium or dev.to. But that would mean giving up ownership of your content.\n\nstandard.site lets you keep your own website and register it – and its content – to a decentralized index that any client can search. A bit like what Google is supposed to be: making content discoverable.\n\nATProto\n\nThe AT Protocol is a decentralized social networking framework that lets you write records – custom JSON – onto a shared database. standard.site is a lexicon built on top of it. To understand how it all fits together, let’s look at the two main concepts.\n\nUser identity\n\nEvery user has a unique DID (Decentralized ID).\nDIDs aren’t human-readable, so users also have a handle on top of them. For instance, my handle is ayc0.dev and my DID is did:plc:wifmfjqoxnruni5h62e6zp2y.\n\nHandles can come from AT Proto providers like BlueSky, or from custom domains. For custom domains, you prove ownership by hosting your DID at /.well-known/atproto-did, like mine at https://ayc0.dev/.well-known/atproto-did.\n\nYou can browse all records in the ATmosphere at https://pds.ls/.\n\nstandard.site lexicon\n\nstandard.site is based on four types of records:\n\n- publication – a website or blog,\n- document – a page, article, or blog post,\n- recommend – a like, similar to YouTube or social media,\n- subscription – which publications a user follows, like an RSS feed.\n\nSee examples of all of those in https://pds.ls/:\n\n- All publications I have created\n- This publication / blog\n- All documents / all posts I posted\n- 1 specific document (for this post)\n- All my recommendations\n- 1 specific recommend (for this post)\n- All my subscriptions\n\nSetup\n\nAt the moment of writing, I’m using sequoia, a CLI to help manage content published to standard.site. As this is an open standard, any other tool or manual scripts would work, but I find sequoia quite convenient.\n\nMost of the setup is explained in https://sequoia.pub/quickstart, but in short:\n\n- tell sequoia who you are via sequoia login / sequoia auth so it can publish records on your behalf,\n- configure sequoia with information about your website (its URL, its ID on standard.site, etc.)\n\nDuring authentication, sequoia generates an ID for your publication that you need to host at /.well-known/site.standard.publication. Mine is at https://ayc0.dev/.well-known/site.standard.publication. This proves to standard.site tools that you own the website.\n\nPublishing articles\n\nEach article needs an atUri defined in its metadata. As I’m using Astro, this is stored in the frontmatter of each article. These are auto-generated and auto-filled by sequoia via sequoia publish. See the docs for details.\n\nWhen publishing an article, I run this CLI at the same time as uploading, to update the ATmosphere.\n\nOnce an article is published, you can use the site validator to confirm everything is correctly set up.\n\nInteractions\n\nSequoia ships UI components for:\n\n- subscriptions,\n- recommendations,\n- comments and replies via BlueSky posts\n\nAll are optional. When used, they prompt users to log in via their ATmosphere account (BlueSky, Tangled, Eurosky, etc.). All of those can be swapped out for custom implementations if needed, as none are sequoia-specific: the underlying data lives in the ATmosphere.\n\nSubscriptions\n\nSubscribing to a publication adds a record to the decentralized database, but doesn’t do anything on its own. You need a client to read the content of the publications you follow:\n\n- https://pckt.blog/read?filter=hot\n- https://leaflet.pub/reader/trending\n- https://skyreader.app/\n- https://glean.at/\n\nWebSocket Feeds\n\nThe AT Protocol pushes events via WebSocket. Every time a record is published, it can be picked up via feeds from any instance.\n\nPDS.ls exposes these – for example, this feed listens to any new post (collections=site.standard.document) published by me (dids=did:plc:wifmfjqoxnruni5h62e6zp2y).\n\nAny client can be built on top of WebSockets using subscriptions, publications, and custom search.\n\nOpenness\n\nAll ATmosphere data is public, which means:\n\n- anyone can publish records (with an account),\n- anyone can read any record.\n\nSo by definition: your BlueSky likes, recommendations, and subscriptions are all public. A client could look at your BlueSky followers, check which ones have standard.site publications, and suggest you follow them – which is exactly what Skyreader does.\n\nTo me, this is a good idea: you can build a client where anyone can follow creators’ publications without needing an account. It also creates more transparency on why certain feeds recommend certain posts – in trending sections, for instance.\n\nConclusion\n\nThis was a very brief and not very detailed overview of the AT Protocol and how to publish articles via the standard.site lexicon.\n\nIf you want to see actual examples of how I implemented standard.site for this website, check out these two PRs:\n\n- #245,\n- #260.",
  "title": "Deploying to standard.site"
}