standard.siteとは結局なんなのか

はじめに

standard.siteとは、atprotoブログサービスの標準スキーマ……とは、実はちょっと違います。
特に、「既に自分のブログ持ってるし移行するつもり無いからなあ」みたいな勘違いを解消することがこの記事の目的です。

Blueskyが表示に対応したことで一躍注目を集めるだろう今、standard.siteの解像度を上げて通ぶれるようになりましょう。

注意: この記事の内容は公式情報からの個人的な推測が含まれています。部分的には中の人から肯定をもらっていますが、経緯や意図は誤っている可能性があります。

standard.siteのひみつ

standard.siteホームページを見ると、長文コンテンツの発見・インデックス・移行("discover, index, and move")が目的として挙げられています。注目したいのは、執筆については触れられていないこと。

ページを読み進めていくと、刊行物(典型的にはブログ)全体や個別の記事に対応するスキーマが登場しますが、記事に対応するsite.standard.documentの本文に相当するcontentはオプションフィールドで、フォーマットも決まっていません。
実際のstandard.siteデータでは、contentがMarkdownやHTMLなこともあれば、JSONオブジェクトなこともあるし、省略されていることもあります。
本文が無い記事とは一体どういうことなのか。

ネタばらしをしてしまうと、standard.siteは長文コンテンツそのものではなく、コンテンツメタデータの標準スキーマです。
本文をstandard.siteに含めるのは検索やプレビューの観点で便利ですが、無くても記事本体へのリンクさえあれば十分ですよね。

ただし、これはstandard.siteだけで完結しないという意味でもありません。
本分がメタデータだとしても、記事全文を含めることはできるわけですから、適当なビューアさえあればブログとして機能します。

standard.site対応するには

メタデータを付ける対象はatproto上のブログサービスである必要は無く、既存のブログでも、何ならブログでないウェブサイトでも構いません。
ただし、メタデータを発行するだけではなく、記事の方からもメタデータへ<link>を張る必要がある点には注意してください。^[1]

メタデータ発行とリンクを自動化する手段になるのが、出たばかりのWordPressプラグインだったり、Markdownブログ向けのSequoiaだったりするわけです。対応するツールが無くても、Standard Site Hubのようなツールでメタデータ発行を補助することは可能です。
もちろんstandard.site対応ブログサービス(Leaflet, GreenGale, mochott, etc.)を使うこともできます。

対応すればBlueskyでプレビューできたり、グローバルに検索できたり、RSS的に購読できたりします。

おまけ: standard.siteの見所

ということで、この記事の本題はここまでです。
ここからは、折角なのでstandard.siteの詳細について少し語ります。

standard.siteは今やatproto公式ブログで採用されたりBridgy Fedが利用したりと、ATmosphereの中でもかなり大きな存在になっています。
それはatproto長文最大手であるLeafletが旗振りしてることもあるでしょうが、メタデータに徹するというコンセプトが寄与しているところは大きいでしょう。

standard.siteは先述のように非atprotoコンテンツも扱えますし、本文形式は参照スキーマすら用意していません。互換性の担保までは踏み入れておらず、記事本体はあくまで各実装の領分です。 ^[2]

atprotoの強みは発見・集約なので、そこだけを別レイヤーに分けて全振りした設計と考えることもできます。
ある意味では、Blueskyよりよほどatprotoらしいと言えるかもしれません。^[3]

個人的には、こういう設計はまだ鉱脈が埋まっていそうなので、もっと開拓されてほしいところです。パッケージマネージャ系やポッドキャスト系だと本体をURL参照する形式は見かけますが、standard.site的な性質を持たせたいならウェブコンテンツである必要はあるかも、とか考えています。
ECサイトを対象にしたOpen Marketは類型と言えるかもしれません。

atprotoで何か作りたいけどアイディアが無い、という人はstandard.site的なデザインパターンがハマりそうなコンテンツを探してみるのも一興かもしれません。