- Hardcore IndieWebは、コンテンツの原本と公開可能なHTML・Web資産を自分のデバイスに保管し、サービス事業者にアイデンティティやコンテンツの制御権を委ねない方法である
- HTMLをブラウザでプレビューしてからホストにアップロードする1990年代式の公開プロセスに従えば、CMS・SSG・フレームワーク・CLI・月額サブスクリプションなしでサイトを運営できる
- テキストエディタとSFTPツール、Webホストだけがあればよく、NearlyFreeSpeech.netでは静的サイトを1日$0.01で運営でき、$0.25からチャージできる
- ランディングページ、個別投稿、アーカイブ、Atomフィードをファイルとして直接管理し、ページごとに構造やデザインを変え、変更されたファイルだけを転送できる
- ホストが消えても完成済みのサイトを別の場所にそのままアップロードできるが、ツールを追加するほど依存関係も増えるため、ローカルの原本と公開版を持つことが独立性を保つ条件である
Hardcore IndieWebが求める独立性
- IndieWebは、Web上のアイデンティティとコンテンツを自分で所有し、企業による外部からの制御から離れようとする実用的なアプローチである
- サブスクリプション型ブログサービスもIndieWebへの参加を助けられるが、コンテンツが主に他人のデータベースやサーバー上に存在するなら、完全に独立しているとは言えない
- 公開形式でエクスポートできるとしても、サービスを利用している間はコンテンツを完全には制御できない
- 既存サービスに満足している人よりも、コンテンツに対する完全な独立と制御を求める人に向いた方法である
- Hardcore IndieWebは、既存のIndieWeb原則に制御権と移植性という具体的な基準を適用する
- コンテンツが主に自分のハードドライブ上にないなら、完全に制御しているとは見なしにくい
- 公開済みのHTMLとWeb資産のコピーがハードドライブ上にないなら、サイトは完全に移植可能な状態ではない
- サービスが廃業してデータをエクスポートできなくなれば、名目上はコンテンツ所有権があっても、アクセスしたり移行したりできない
- 運営者の行動が理由でサービスを離れようとしても、エクスポート形式をサポートする別のサービスを探すか、コンテンツを変換し、ツールや手順を変えなければならない場合がある
- ローカルにコンテンツの原本と完成済みの公開版があれば、こうした状況でも制御権と移植性を維持できる
1990年代式のWeb公開手順
- Hardcore IndieWebは、Web初期のシンプルな公開方法に従う
- ハードドライブ上でコンテンツを作成する
- Webブラウザでプレビューする
- 満足したらWebホストにアップロードし、必要なたびに繰り返す
- ドメイン以外に必要なのは、テキストエディタ、ファイル転送ツール、Webホストだけである
- プログラミング環境やIDE、フレームワーク、シェル、CLIツール、月額サブスクリプションは不要である
- HTMLの知識は必要だが、HTML for Peopleのような資料で学べ、少数のタグとコピー＆ペーストだけでも始められる
- 複雑なSaaS・CMS・SSG・マークアップ言語・テンプレートシステムは任意であり、ファイルを直接公開するシンプルな方法も今なお機能する
必要なツールとホスティング
- テキストエディタは、ディスクにファイルを保存できるものなら何でも使える
- Adam Newboldは、ファイル転送までサポートするNovaを使っている
- 他の選択肢はテキストエディタ一覧で探せる
- ファイル転送には、SSHまたはSFTPをサポートするツールが必要である
- FileZillaは、複数のOSをサポートする選択肢である
- 静的サイトホストとしてNearlyFreeSpeech.netを推奨しており、1日**$0.01**で運営できる
- Adam Newboldは2008年からこのサービスを使ってきた
- $0.25からアカウントにチャージし、
static, non-productionサイトを追加できる Sitesタブでサイト名を選ぶと、ファイル転送用のログイン情報を確認できる- 無料サブドメインが提供され、
Domainsタブで個人ドメインを追加できる
- NearlyFreeSpeechは必須ではなく、基本的な静的ファイルホスティングを提供する他のWebホストも選べる
既存サイトとHTMLの準備
- 既存サイトやブログがHTML形式なら、すぐに始めやすい
- 他の形式で運営中なら、サービスによってはHTMLへエクスポートまたは変換できる
- 規模の大きいブログには変換ツールを使うほうが適している
- 規模が小さいなら、投稿を見直しながらHTMLファイルを直接作れる
- Markdownを好む場合もあるが、HTMLはWebの言語であり、Markdownパーサーと格闘するより純粋なHTMLで処理するほうが簡単なこともある
- 最初からデザインするのが難しければ、HTML5 UPのような無料デザインやテンプレートをダウンロードして編集できる
ブログを構成するファイル
- 一般的なブログはランディングページ、投稿、アーカイブページ、フィードで構成され、専用ブログサービスなしで直接管理できる
-
ランディングページ
- 最新投稿の全部または一部、複数の投稿、あるいは投稿ではないコンテンツを自由に配置できる
- 最新投稿を表示するには、内容をコピーし、独立ページへのリンクを追加する
- 直近5件の投稿を維持するには、新しい記事を上に貼り付け、最も古い記事を下から削除する
- CMS・SSG・テンプレートエンジンの制約がないため、ページごとに構造と表現を変更できる
- ランディングページのファイル名は
index.htmlでなければならず、Webルートに置く - NearlyFreeSpeechのWebルートは
/home/publicである
-
ブログ投稿
- 投稿1件をWebページ1つとして作り、過去の投稿ファイルをコピーして固有のファイル名と新しい内容を入れる方法で作成できる
- ディスク上のファイル構造がURLに反映されるため、望むURL体系に合わせてフォルダを構成する
/blog/パスを使うには、Webルートにblogフォルダを作るthe-best-lunch-i-ever-had.htmlのようなスラッグベースのファイル名を使える- 投稿ごとのフォルダ内に
index.htmlを置くと、URLから.html拡張子を隠せる - 投稿をMarkdownやデータベース項目ではなく独立したHTMLファイルとして管理すれば、記事ごとに異なるスタイル、外観、レイアウト、個性を与えられる
- すべての投稿が同じ見た目であるべきだという慣習は現代的な公開ツールに由来するもので、手作りのHTMLでは従う必要がない
-
アーカイブページ
archiveのような名前のフォルダを作り、その中にindex.htmlを置いて投稿一覧を作成する- 並び順や構成は自由で、気に入っている投稿をページ上部で別途強調することもできる
Atomフィードを直接管理する
- RSSフィードは特別なシステムではなく、ディスクに保存するファイルなので、テキストエディタで直接修正できる
- WikipediaのAtomページ)にあるサンプルフィードをコピーし、
feed.xmlファイルとして始められる- AtomはRSSと互換性があり、広くサポートされている
example.com、<title>、<subtitle>などの値を自分のドメインと情報に変更する- フィードに入れる投稿ごとに
<entry>を作り、日付・時刻・タイトル・要約などを入力する <id>にはUUID Generatorで新しいUUIDを取得して使う
- 完成したフィードはW3C Feed Validation Serviceに貼り付け、パース可能かどうかを検査できる
- エラーが見つかった場合は、検証サービスで修正すべき項目を確認できる
公開と更新
- 初回公開時は、ファイル転送プログラムでサーバーに接続し、サイト全体をWebホストへコピーする
- その後は、新しく作成された、または変更されたファイルだけを転送すればよい
- 一般的な更新対象は、ランディングページ、新規投稿、フィード、アーカイブページである
- 公開プロセスは、ローカルファイルをリモートサーバーへドラッグ＆ドロップする程度で処理できる
移植性と追加ツールの境界
- 完成済みのサイトが自分のコンピュータ上にあるため、既存ホストが消えても別のホストにそのままアップロードできる
- ブログソフトウェアの重大なセキュリティ脆弱性やSSG依存関係を管理する必要がなく、コンテンツのあらゆる側面を直接制御できる
- この手順をそのまま維持するだけで、完全に独立したWebサイトを運営し続けられる
- 作業フローを助けるツールや手順を追加できるが、ツールを1つ足すたびに新しい依存関係も生じる
- コンテンツの原本が自分のデバイス上にあり、公開可能なサイト全体のコピーを持っているなら、Hardcore IndieWebの条件を満たす
HTMLを直接扱う自律性
- 中核となる手順は、HTMLを直接書いてWebサーバーにアップロードすることである
- 過去30年で追加された技術レイヤーや手順、期待水準はWeb作業を複雑にし、制御権と独立性を他人に渡すことにつながった
- IndieWebサービスを使っていても、Web上の存在全体の唯一のコピーをサービス運営者に預けるなら、完全に独立しているとは言えない
- Hardcore IndieWebはすべての人向けの方法ではないが、自分の文章を誰が保持し、どこにどのような形で公開するかを重視する人に適している
- HTMLを直接扱い、自分のWebホスト領域へファイルをコピーするプロセスは、初期Webの楽しさと再びつながる直接的で自律的な体験を提供する
1件のコメント
Hacker News のコメント
静的サイトを GitHub Pages と Cloudflare Pages で無料ホスティングしてきており、とても満足している。NearlyFreeSpeech に費用を払ったとしても、結局サードパーティのホスティングに依存する点は同じなので、自分でホスティングすることには技術的な満足感以外に大きな価値はなさそうに見える
重要なのは、HTML や画像のようなアセットをディスク上の単純なファイルとして直接管理する点だ。Git 連携のおかげで外部バックアップにもなり、VS Code から
masterにプッシュすれば 30 秒以内に公開されるので、昔の FTP/SFTP よりはるかに便利NearlyFreeSpeech も良いサービスだが、完全に独立しているわけではない。自前のインターネットインフラなしで独立性に最も近づくなら、自宅でポートフォワーディングするか、Tor 隠しサービス としてサイトを運営できる
torrcでポートを設定すれば難しくはないが、訪問者にも Tor Browser が必要で、サイトが「ダークウェブ」にあると説明するのが厄介だ。所有するハードウェアで自宅運用でき、サーバー IP も隠せるのに、独立系ウェブの界隈でより広く使われていないのは意外だ。通常のドメインを.onionアドレスへリダイレクトすることもできるブラウザ上で直接サイトを作成・ホスティングできた Beaker Browser は終了したが、Tor 向けサイト制作プラグインのようなツールが出てくれば普及の助けになりそうだ
.onionサービスは簡単に立ち上げられ、通常のウェブより安全で、携帯電話上でも実行できるNanogram: https://gitlab.com/here_forawhile/nanogram
Spreadsheet Server: https://gitlab.com/here_forawhile/spreadsheet
Library Server: https://gitlab.com/here_forawhile/libraryserver
Torum: https://gitlab.com/here_forawhile/torum
.onionアドレスを見つけられるよう、Onion-Location と Alt-Svc をサポートしている。Onion-Location は通常の HTTPS サイトが Onion サービスを知らせるもので、Alt-Svc はユーザーの追加操作なしに自動で発見して切り替える将来的には DNS や DNSSEC ベースの Onion 接続も可能性がある: https://onionservices.torproject.org/research/proposals/usab...
myfirstnamelastname.comを教えるのと、56 文字のランダムな.onionアドレスを伝え、携帯電話に Tor Browser までインストールしてあげるのとでは、アクセスしやすさに大きな差があるこの流れで最大の障壁は、コンテンツ所有に必要な ドメイン名 であり、安くても年間約 6 ドルかかる。静的サイトは無数の場所で無料ホスティングでき、個人には CDN の無料枠で十分だ
サーバーを自前ホスティングすることより重要なのは、ドメインという一意の識別子を所有することであり、そのドメインがどこを指すかははるかに重要度が低い
Web サーバーに自分のファイルを置くことが、まるで 新しい概念 のように扱われているのはおかしい
直接ホスティングする技術は今もあるが、考え方がクラウド専用へと変わってしまった
public_htmlフォルダにファイルを入れるだけで、すぐに個人ウェブサイトができた。HTML をずっと手書きしなければならないという意味ではないが、当時は素早く自然にウェブへ参加する方法だったUnix アカウントは
fingerで友人の接続状況を確認し、talkやytalkで会話する個人間チャットまで提供しており、隣の端末に友人が座っていても魔法のように感じられた1日0.01ドルを支払う NearlyFreeSpeech が「100%独立運営」だというなら、Vercel、Netlify、GitHub、Cloudflare の静的ホスティングと大きな違いはないように見える。
データベース、フィードバックフォーム、ソーシャルメディアのプレビュー、検索エンジン最適化が必要なときはどうするのか記事には書かれていないが、おそらくそうしたものがないことが「独立したWeb」の条件なのかもしれない。
イベント用Webサイトにドメインが必要だったが、Infomaniak はドメインに加えて 10MB のストレージも提供していた。年間約5ユーロでドメインとサイトの両方を用意できるので悪くない
Git リポジトリ内にすべてのデータを保存するコメント用 JavaScript プラグイン https://github.com/est/req4cmt を作った。Git サービスが HTTP に対応していれば利用でき、無料の Cloudflare Worker 上で動作し、バックアップと移行は
git cloneとpushで終わる。Git ベースの Twitter 代替プロジェクトもある: https://github.com/est/gitweets
デモは https://f.est.im/ で、Git notes を使ったコメントにも対応している。Cloudflare Workers と GitHub Pages のおかげで、すべて完全に無料
sdf.org は Unix システムを直接学びたい開発者に有用。NetBSD Unix の無料シェルアカウントを提供しており、少額の一回限りの寄付でWebスペースや追加機能を利用できたと記憶している。
ログイン名がWebスペースのサブドメインになるので、慎重に選ぶ必要がある
こうした主張をするサイトが Cloudflare や GitHub Pages 上に置かれていないのはうれしい
特定のツールよりも、プロセスを学び所有することを好む。Markdown のような読み書きしやすい形式から Pandoc などのツールで HTML を作り、HTML・CSS・JavaScript をホスティングサービスにアップロードまたは同期する方法を覚え、ドメインを所有して DNS を GitHub Pages や Cloudflare Pages に接続する方法を学べばよい。
特定のツール・サービス・プラットフォーム・会社に縛られないので、いつでもコンテンツファイルを別の場所へ移せる。元の Markdown を HTML に変換する過程は、静的サイトジェネレーターで自動化できる。
HTML を知っていることは有用で楽しいが、「100%独立してサイトを運営」するための必須条件である必要はない。GitHub と Cloudflare で月額0ドルで運営し、サービスが終了したり有料化されたりしたら別の場所へ移せばよい。
プロセスの所有と完全な独立性を望むなら、Web言語を自分で理解し扱える必要がある。Nikola のような静的サイトジェネレーターは便利だが、出力を理解したり直接修正したりできないなら、依然としてサードパーティ製ツールに依存していることになる