- IndieWebは、個人ドメインにコンテンツ・アイデンティティ・会話を保存しつつ、必要に応じてソーシャルネットワークと接続する、企業中心のWebに対する人間中心の代替であり、コミュニティでもある
- 独自ドメインを基盤に、microformats2、
rel="me"、Webmention、IndieAuth、Micropub のような小さな標準を組み合わせ、HTMLを機械可読にし、サイト間の認証・公開・会話を支える - GeoCitiesの2,300万ページとMySpaceの5,000万曲超が消滅し、2024年のPew Research調査でも、2013年に存在したWebページの38%が10年後にアクセス不能だった
- POSSEは原本を自分のサイトに先に公開してから外部プラットフォームへ配信し、Backfeedは外部のいいね・返信・再投稿をWebmentionで原本へ戻して、会話全体を個人ドメインに保存する
- 実際のサイトではWebmention、h-entry、h-card、
rel="me"を適用したが、既存のGit・Markdownワークフローや24時間の公開遅延と合わないMicropub、IndieAuth、WebSubは除外し、あらゆる仕様よりも必要な技術から段階的に導入するのが適している
IndieWebが目指すWeb
- IndieWebは、自らを「企業Webに対する人間中心の代替」と定義しており、特定のソフトウェアやフレームワークよりも、さまざまなアプローチやプロジェクトを受け入れる理念的な基盤に近い
- 2010年、Aaron PareckiとTantek ÇelikはPortlandのFederated Social Web Summitに参加した後、プロトコルよりクリエイター中心のアプローチが必要だと判断した
- 2011年にPortlandで最初のIndieWebCampが開かれ、その後は世界各地で毎年開催されている
- Homebrew Website Clubでは参加者が集まり、自分の個人Webサイトを改善する
- IndieWebを構成する3つの柱は次のとおり
- コンテンツの所有権: Webに載せたコンテンツは企業ではなく投稿者に属すべき
- より良いつながり: 記事を複数のプラットフォームに配信でき、外部の返信やいいねを自分のサイトへ取り戻せるべき
- コントロール: 好きな形式で公開・閲覧でき、永続的なURLを維持すべき
- ソーシャルネットワークの利用自体を禁じるわけではないが、コンテンツと相互作用を囲い込む閉鎖的なエコシステムには反対する
サイロとWebコンテンツの消滅
- サイロ(silo)とは、一般に営利企業が運営し、ユーザーが投稿したコンテンツに対する権利を要求したり、アクセスを制限したりする中央集権的なWebサイトを指す
- 参加にはサービスごとのアカウントが必要
- 同じサービスのアカウント同士でしか相互作用できない
- 制限的な利用規約、コンテンツライセンス要求、検索インデックスの遮断、インポート・エクスポートの障壁が加わることもある
- サイロが終了すると、ユーザーのコンテンツも一緒に消える可能性がある
- GeoCitiesはYahooが2009年10月26日に終了し、2,300万ページが消滅した
- MySpaceは2019年のサーバー移行時に、最初の12年間で1,400万人のアーティストが投稿した5,000万曲超を失った
- **Google+**は2019年4月に終了した
- Posterous、FriendFeed、Vine、Yahoo Groups、TinyLetter、Cohostなども終了したサービスに含まれる
- サイロが閉鎖されなくても、Webコンテンツは失われうる
- 2024年のPew Research調査によれば、2013年に存在したWebページの38%が10年後にアクセス不能だった
- 対応原則はソーシャルネットワークを使わないことではなく、コンテンツの**正本(canonical copy)**を自分が管理するドメインに置くこと
コミュニティの11原則
- 11原則は優先順位ではなく、すべてを満たす義務でもない
- データ所有: コンテンツ・メタデータ・アイデンティティを自分のドメインに置き、長期的なアクセス権を維持する
- 見えているデータを使って公開: 人を優先し、機械はその次に考え、HTMLにデータを埋め込めるなら別個のAPIは作らない
- 自分に必要なものを作る: 実在する自分のための道具を作り、存在が曖昧な仮想ユーザーのためには作らない
- 自分で使う: 作ったものを毎日使い、依存する価値があるかを確かめる
- 文書化: 過程・アイデア・コードを自分のサイトに記録し、他人と未来の自分を助ける
- オープンソース化: 義務ではないが、他の人が独立したWebにより早く参加できるよう助ける
- プロトコルよりUX: まずユーザー体験を定め、それを支える最も単純で小さなプロトコルだけを使う
- モジュール性: 特定の機器・言語・プラットフォームに縛られないよう、小さく疎結合な構成要素を作る
- 長期存続性: 進歩を理由に数年ごとに既存の作業を捨てなくてよいWeb技術を築く
- 多元性: 複数のアプローチを意図的に奨励し、単一の技術文化より回復力のあるコミュニティを作る
- 楽しさ: 1990年代のWebのような、奇妙で面白い個人的表現を保つ
個人ドメインから始める技術構成
- 独自ドメインをオンライン上の主たるアイデンティティとして使うことが、すべての構成の前提
- ホスティングやCMSを変えてもドメインを維持すれば、リンク・読者・検索順位を引き継げる
- コミュニティがIndieWeb参加と認める最低条件でもある
- IndieWebは単一プラットフォームの代わりに、組み合わせ可能な小さな仕様を使い、公式仕様インデックスでは実装の経緯と普及範囲ごとに整理されている
microformats2: HTMLをAPIとして使う
- microformats2は、別ファイルやAPIなしで既存のHTMLにCSSクラスを追加し、コンテンツを機械可読にする
h-*: ルートオブジェクトp-*: プレーンテキストu-*: URLdt-*: 日付e-*: 埋め込みHTML
- h-cardは名前・URL・写真など個人のアイデンティティを表し、アプリケーションが投稿の横にプロフィールを表示し、ユーザーを認識できるようにする
- メールアドレス基盤のGravatarと違い、ドメインを基盤に動作する
- h-entryは、投稿のタイトル、著者、公開日、本文などを表すIndieWebコンテンツの中核要素
- h-feedは複数のh-entryを束ね、HTMLの一覧ページ自体を購読可能なフィードにする
- 読み取りにはmicroformatsを、書き込みにはMicropubを使い、「WebサイトそのものがAPI」という構成を作る
rel="me"と分散型の本人確認
rel="me"は、リンク先が現在のページと同じ人物を表していることを宣言する- Webサイトと外部プロフィールが互いに
rel="me"で結ばれると、中央機関なしで相互本人確認が可能になる- Mastodonはこの仕組みでドメインに緑色の認証表示を出す
- Threads、PixelFed、GitHub、Keybase、Wikipediaも対応している
- RelMeAuthは、ホームページで接続したGitHubのようなOAuthプロバイダーに身元証明を委任し、個人URLでサービスにログインする
- IndieLoginのようなサービスの基盤
Webmention: Webサイト同士の会話
- Webmentionは2017年1月12日からW3C Recommendationであり、Pingbackを継承して、プラットフォームなしでサイト間のコメント・いいね・返信・再投稿を伝える
- 送信手順は次のとおり
- 送信元の投稿が相手の記事へのリンクを含む
- 送信元サーバーが相手記事のHTTP
LinkヘッダーまたはHTMLの<link rel="webmention">から受信エンドポイントを探す - 送信元記事である
sourceと対象記事であるtargetだけを含むPOSTリクエストを送る - 受信サーバーが
sourceを取得し、実際にtargetへのリンクがあるか検証する sourceのh-entryを解析して返信・いいね・再投稿を判別し、h-cardで著者の名前と写真を表示する
- 各サイトがノードとなり、サイト間リンクがソーシャルグラフを構成するが、スパムとモデレーションの問題は残る
- Vouchは、受信者がすでに知っていて送信ドメインへリンクしている保証サイトを第3引数として渡し、フィルタリングのコストを送信者側へ移す
- Salmentionは、コメントに返信が付いたとき、元記事が参加者へ更新Webmentionを再送し、会話スレッドを伝播させる
- バックエンドのない静的サイトでは、webmention.ioがWebmentionを代行受信し、取得APIを提供する
- Hugo、Jekyll、Eleventyのような静的サイトジェネレーターで利用できる
ドメインベースのログインと公開
- IndieAuthは、GoogleやFacebookのアカウントの代わりに個人URLをログイン用アイデンティティとして使う
- OAuth 2.0を基盤に、ユーザーとアプリケーションをURLで識別する
- DNSが事前クライアント登録の代わりを果たし、アクセストークン奪取を防ぐPKCEが必須
- サービスはユーザーページの
rel="indieauth-metadata"から認証サーバーを見つけ、認証完了後にそのURLへの支配権を確認する - 認証方式としてパスワード、メール、RelMeAuthなどを使える
- Micropubは2017年5月からW3C Recommendationで、サイトソフトウェアと公開インターフェースを分離する
- Web・iOS・Androidクライアントが個人ドメイン上の投稿を作成・修正・削除できる
- パスワードを共有していたMetaWeblogやAtomPubの代わりに、IndieAuthで取得したOAuthトークンを使う
- 独自語彙は作らず、
h=entry、contentなどh-entryのプロパティをシリアライズして送る
リアルタイムフィードと分離されたリーダー
- WebSubは以前はPubSubHubbubと呼ばれ、2018年1月からW3C Recommendationとなっている
- 購読者が定期的にサーバーを問い合わせる代わりに、投稿者がハブに新着を通知し、ハブがWebhookで購読者へ即時配信する
- サーバー負荷を減らし、更新遅延をなくし、FeedlyやNewsBlurなどが対応している
- Microsubは最も新しい仕様で、まだ草案段階にあり、ソーシャルリーディングアプリケーションを2層に分離する
- サーバーは購読管理、フィード収集・分析、データ正規化を担当する
- クライアントは読むためのインターフェースだけを表示してUXで競争でき、購読情報はクライアント間で移動可能
- Micropubによる返信投稿とWebmentionの通知を組み合わせれば、IndieWebのソーシャルリーダー構成が完成する
POSSE、PESOSとBackfeed
- POSSEは、自分のサイトに先に公開して外部へ配信する推奨戦略
- 外部コピーには原本リンクが含まれるため、読者は既存プラットフォームで読み続けられ、投稿者は正本を維持できる
- プラットフォームが終了したりアカウント停止になったりしても原本は残る
- Tantek Çelikが2012年に用語を作り、Cory DoctorowやMolly Whiteらが使っている
- スパムサイトが記事をコピーしても原本リンクまで一緒にコピーさせる効果を「インターネット合気道」と呼ぶ
- PESOSは、サイロに先に投稿してから自分のサイトにコピー保存する逆の方式
- 完成度の高いサイロアプリを使え、個人サイトが止まっていても投稿できる
- 最初からサイロの規約が適用され、個人サイト上のコピーは正本ではなく、文字数制限や
t.coリンクのような制約まで引き継ぐ
- Backfeedは、外部コピーに付いたいいね・返信・再投稿をWebmentionで原本へ戻す
- BridgyはMastodon、GitHub、Flickr、Reddit、Bluesky上のコピーを監視し、相互作用のたびにWebmentionを送信する
- 結果として、外部プラットフォームで発生した会話全体を個人ドメインに保存できる
FediverseおよびRSSとの関係
- Webmention、Micropub、WebSub、ActivityPubはいずれもW3C Social Web Working Groupから生まれたが、それぞれ異なる思想に従っている
- Fediverseはサーバーを連合し、アイデンティティを
@user@instanceで表すため、自前インスタンスを運用しない限り他の運営者に依存する- インスタンス運用には、モデレーションと保守の高コストであるadmintaxが伴う
- IndieWebはWebサイトを連合し、個人ドメインをアイデンティティとして使い、連合は複数の配信チャネルの一つとして扱う
- Bridgy Fedはh-card、h-entry、WebmentionをActivityPubおよびBlueskyのAT Protocolと相互変換する
- 個人ドメインが
@example.com@example.com形式のFediverseアカウントになる - Mastodonでそのアカウントを検索・フォローでき、返信はBackfeedで元投稿へ戻る
- 個人ドメインが
- IndieWebは、RSS・AtomがHTMLとは別にXMLコピーを維持する必要があるため、保守コストと不一致の可能性を生むと考える
- 一部のAtomファイルは、同内容のHTMLより最大4.5倍大きい
- 人がフィードリンクを直接開いたときの体験も良くない
- 代替であるh-feedはHTML自体をフィードとして使うが、対応するリーダーが非常に少ない
- そのためIndieWeb環境にはh-feedを、一般読者にはRSS・Atomも併せて提供することが推奨される
始める順序
- Getting Startedは次の順序を勧めている
- ドメイン取得: オンライン上の主たるアイデンティティとして使い、WHOISプライバシー保護は提供者を完全に信頼できるときだけ選ぶ
- ホスティング構成: 初心者はGitHub Pages、Netlify、Neocitiesのようなマネージドサービスを使い、経験者なら自前ホスティングする
- ページ作成: 静的サイトジェネレーター、手書きHTML、CMSのどれを使ってもよく、公式技術はない
- POSSEの適用: 原本リンク付きで他プラットフォームに配信する
- microformatsの追加: ホームページに
rel="me"、投稿にh-entryを入れる - 検証: IndieWebify.meでrel-me、h-card、h-entryを段階的に確認する
- コミュニティ参加: 1ページだけでも作ったものを共有し、次の利用者のためにWikiへ記録する
- IndieMarkは、段階的に導入したい開発者向けのステップ別ガイド指標
実際の導入と除外した機能
- 実際のサイトには次の要素を導入した
- Webmentionの送受信: 新しい記事の外部リンクへの通知を日次処理として自動化しつつ、タイプミスを直せるよう24時間の猶予を置く
- 受信したWebmentionは各記事末尾の参考リンク一覧に使い、メール管理しているコメントとは分離する
- すべての記事にh-entry、ホームページにh-cardを適用し、mf2pyで検証する
- フッターでMastodon、GitHub、Org Socialを
rel="me"で結び、認証表示を得る
- 必要性や既存ワークフローと合わない要素は除外した
- Micropub・IndieAuth: エディタとGitが公開インターフェースであり、記事をバージョン管理されたMarkdownで書くため、別個の公開エンドポイントは不要
- WebSub: 意図的に公開を24時間遅らせているため、リアルタイム配信は複雑さを正当化しない
- h-feed: 記事カードのテンプレートが本文内のおすすめ領域などにも再利用されており、パーサーが曖昧なh-entryとして認識する可能性があり、RSSがその役割を十分果たしている
技術より長く残る実践原則
- プレーンなHTMLは、JavaScriptなしでも全コンテンツを読める、最も長持ちする形式
- 「Cool URIs don't change」の原則に従い、永久に維持できるURLを設計すべき
- 実際のサイトでは記事のスラッグを変えても既存URLが引き続き機能する
- サイロを一度に離れる必要はなく、コンテンツ種別ごとに自分のサイトへ先に公開する段階的移行が可能
- 極端な長期存続性まで考慮する必要がある
- 死後に信頼できる人へサイトの鍵を引き渡す「dead man's switch」を検討できる
- 運営者がいなくなった後、誰がドメイン費用を払うのかも解決しておく必要がある
- 完璧だが維持が退屈なテンプレートより、不完全でも独自性のある個人Webサイトを楽しく運営するほうがIndieWebの原則に合っている
1件のコメント
Hacker Newsのコメント
IndieWebがコンテンツを求めるなら、複雑な技術の山の下に埋めてしまうやり方は正反対だ
このプロトコル群はユーザーの90%にとって実質的に使えず、コンテンツのユーザー体験を優先するなら、すぐ始められるワンクリックの解決策が必要だ
コマンドライン・Docker・HTML/CSSの直接編集を要求した瞬間に、大半が越えられない壁を作ることになり、今の姿はIndieWebというよりNerdNetに近く見える
代表的なワンクリックの入口であるmicro.blogは、最新のIndieWeb機能を備えた個人サイトを月5ドルで提供している
現在の関心層の多くが自分で構築したい開発者なので、関連する文章が技術だらけに見えるが、非開発者の流入もコミュニティが望む変化だ。David Shanskeは過去10年間、IndieWebツールを標準提供するWordPressプラグインを作ってきた: https://profiles.wordpress.org/dshanske/#content-plugins
すべての技術を使わないとIndieWebではない、というわけでもない。独自ドメインから始めて、HTML・Markdown・Djangoなどでページを作り、マイクロフォーマットとWebmentionを順に追加すればよく、どの段階でもIndieWebサイトと見なせる
インターネットは、世界的なWalmartになる前の、面白い人たちが自発的に集まっていた空間だったころのほうが良かった
インターネットも常に、変わり者が作った難しいが面白いものから始まり、徐々に一般人が使いやすくなる形で発展してきた。IndieWebも初期段階であり、生き残るなら大衆化は自然についてくるので、今はもっと作らせておけばよい
問題は経済性だ。ワンクリックの解決策は良いが、IndieWebはイデオロギー上の問題は解決しても、ユーザーの切実な問題は解決できないため、投資やサービス運営費を賄える顧客を確保しにくい
micro.blogが最も近いが、自前インフラで運用できない中央集権型サービスなので、プロトコル互換性はあっても完全なIndieWebツールではない
エージェント活動記録やセンサー・サーバー向けの投稿ツールのような可能性はあるが、実質的なユーザー需要がなければ完成品サービスとして成り立ちにくそうだ
人気のあるものに屈するより、欲しいものを作るよう促すべきだ。実質的な価値を作るよりレントシーキング戦略やロビー活動に没頭するマーケティング職は社会を悪くするので、減ったほうがよい
Nostrの考え方は、MastodonやAT ProtocolよりPOSSEに近く見えるので好ましい
定期的にブログを運営し、ドメインも投稿も所有しているが、WordPressを使ったという理由でIndieWebではないなら、結局は企業に依存していることになる。以前Bloggerで作ったブログも、もうほぼ10年間そのまま残っている
サーバーを自分で所有することは現実的ではない。仮想サーバーならAmazonやMicrosoftのクラウド上にあり、物理サーバーでも企業のデータセンターに置く必要があり、UPSや常時インターネット接続まで自分で管理するのは難しい
既存の代替案はたいてい1990年代ノスタルジーを追うだけで、一時的な懐かしさ以外の価値を見つけにくかったが、このやり方は違って見える
現代のWebを受け入れつつ、創作者が自分の空間を完全に制御できるようにしてくれる。時間ができたらmyzopotamia.devのブログをIndieWebに参加させたい
indiekitは事実上、IndieWeb機能一式を標準で提供している。https://rmendes.netで使っており、https://textcaster.appにも実装しようと作業中だ
RSSフィードの**重複排除原則(DRY)**の問題は誇張されているように思う。どんなオープンソースのフレームワークで書いていても、RSSフィードの自動生成で問題が起きた記憶がない
h-entryがあるのに同じコンテンツの2つの版とXMLを管理しなければならず、しばしばうんざりしたRSSはテーブルベースのレイアウトが終わりつつあったセマンティックマークアップ革命の直前に発明され、時期が良くなかった
IndieWebを掲げるサイトで、著者の履歴書、プロが撮った顔写真、名門機関での経歴を強調した紹介文や洗練されたブログを見ると居心地が悪い
高級ショッピングモールの明るい服屋で、すべての商品にアナーキズムのシンボルを貼ってあり、近くで見ると値札がほぼ4桁という光景に似ている
個人サイトは、望むものなら何にでもなれる。私のサイトも就職活動をする必要がなくなってから、年々より個人的で趣味中心になっているが、サイトは結局その人が生きる社会の産物であり、生計も立てなければならない
職業生活も私を構成する一部であり、自営業者という意味で独立労働者と呼ぶこともできるが、それの何が悪いのか分からない
IndieWebは専門性を拒否しておらず、コンテンツは自分に属し、プラットフォームより長く生き残るべきだと考える。顔写真・履歴書・洗練されたブログは問題なく、閉鎖されたり、データを売られたり、消えたりするかもしれないプラットフォームの中に閉じ込めることこそ批判の対象だ
並列ファイルやAPIなしでコンテンツを機械に読ませることは、そもそも解決する必要がほとんどなかった問題だ
以前のオントロジーと同様に、人間の訪問者には役に立たず、敵対的な主体にデータを食わせるだけだ
好きな他のブログを継続的に共有するとよい。IndieWebは口コミと人によるキュレーションに依存するので、「今月楽しんだもの」のような記事が役に立つ
惜しみなく褒め、メールで感謝を伝え、会話を始める必要もある。ユーザー追跡のない静的サイトは独り言のように感じられることがあり、読者からのメールは大きな励みになる
個人サイトらしく、不完全で風変わりでも構わず、すべてのコンテンツが時系列フィードである必要もない。デジタルガーデンのように好きな形で空間を構成すればよい
.devドメインがGoogle所有だと知っていたのだろうか