{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreih2x4l6lsmfaul5svr7lmsmxbgfwdom6huxbojfpqzfph6egw7wye",
"uri": "at://did:plc:gevyqibw5p2xsonkbsbjm5vy/app.bsky.feed.post/3mnqqtepjsx24"
},
"description": "Wiring up Standard.site on my blog.",
"path": "/blog/hello-standard-site",
"publishedAt": "2026-06-07T00:00:00.000Z",
"site": "at://did:plc:gevyqibw5p2xsonkbsbjm5vy/site.standard.publication/3mnqgth7gxo2f",
"tags": [
"post",
"bluesky",
"atproto",
"standard.site"
],
"textContent": "I Sat Down to Try My Hand at Standard.site\r\n\r\nIn a little less than two hours or reading and poking around, writing the code, I decided to just do it and see what it does.\r\n\r\n What is Standard.site?\r\n\r\nIf you use Bluesky, you already know the AT Protocol. It's the open protocol powering the network.\r\n\r\nStandard.site(https://standard.site/) is a set of lexicons built on top of it that let your website register itself as a publication on the protocol. Think of it as RSS for the ATmosphere. People can follow your domain the same way they follow an account on Bluesky, and your posts show up in aggregators like Read on pckt and Docs.surf.\r\n\r\nThe appeal for me was that I already had Bluesky autoposting wired up. This just takes it further. My content lives on my domain, and the AT Protocol knows about it.\r\n\r\n What the Implementation Looks Like\r\n\r\nThere are three parts:\r\n\r\n A publication record. A onetime script that registers toddl.dev as a publication on your PDS. You get back an ATURI that identifies your site on the network.\r\n A .wellknown endpoint. A single file at /.wellknown/site.standard.publication that returns your publication ATURI as plain text. This is how the network verifies you actually own the domain.\r\n Document records. One record per post, each linked back to the publication. Each post page gets a <link rel=\"site.standard.document\" tag in the <head pointing to its record.\r\n\r\n Fitting it Into the Existing Workflow\r\n\r\nI already had a posttobsky script that posts to Bluesky and writes the post ID back into the frontmatter. Adding Standard.site was just a few more lines at the end of that same script. Authenticate, create the document record, write the ATURI back into frontmatter alongside the Bluesky post ID.\r\n\r\nNow the publish flow is exactly what it was before: npm run posttobsky slug=yourpostslug\r\n\r\nOne command. Bluesky post goes out, Standard.site document gets registered, both IDs land in the frontmatter. Then commit and push.\r\n\r\n Backfilling Existing Posts\r\n\r\nSince I had 74 posts already live, I wrote a backfill script that looped through every markdown file, registered each one as a document record, and wrote the ATURI back into the frontmatter automatically. Skipped drafts and anything already registered so it was safe to rerun if something failed partway through.\r\n\r\n Is it Worth Doing?\r\n\r\nIf you're already on Bluesky and you own your content on your own domain, yes. It takes maybe an hour to implement and your entire back catalog becomes discoverable on the open web in a new way without handing your content to any platform. I like to own my own content, and with how things are today, I am taking my content and keeping it close to me.",
"title": "Hello Standard.site"
}