GitHubからDilloプロジェクトを自己ホスティングへ移行

 (dillo-browser.org)
2 ポイント 投稿者 GN⁺ 2025-12-01 | 1件のコメント | WhatsAppで共有
  • Webブラウザ DilloプロジェクトがGitHubから自己ホスティングサーバーへ移行を進めている
  • GitHubのJavaScriptへの依存、単一管理構造、低速なパフォーマンスなどが主な移行理由として挙げられている
  • 新サーバーはdillo-browser.orgドメインで運用され、cgitベースの軽量Gitフロントエンドと自作のバグトラッカー**『buggy』**を使用
  • すべてのデータはgitリポジトリで管理され、CodebergとSourcehutにミラーされ、データ喪失リスクを最小化している
  • OpenPGP署名によりDNS喪失時でも信頼性を保てるよう設計され、プロジェクトの独立性と継続性が強化される

背景

  • Dilloの元のサイトは以前はdillo.orgで、Mercurialリポジトリ、メールサーバー、バグトラッカー、メーリングリストのアーカイブを含んでいた
    • 2022年にドメインを失い、第三者がAI広告だらけの類似サイトを開設
    • 一部の資料は復旧したが完全ではない
  • この経験を踏まえ、単一サイト依存を避け、分散型のバックアップ構成を構築することにした
  • 当初はGitHubにコードをアップロードしたが、長期的には適していないと判断した

GitHubの問題点

  • GitHubはCIワークフローとリポジトリ管理に有用だったが、いくつかの制約がある
    • JavaScriptがないとフロントエンドが動作せず、DilloブラウザーでIssueやPRを閲覧できない
    • ページがリソースを過剰に使用し、単純なHTMLレンダリングでも不要な負荷が発生
  • 単一管理主体によってアカウントが停止されるリスクがあり、データアクセスが遮断される可能性がある
  • プラットフォームが次第に遅くなり、より高速なインターネット接続を要求している
  • GitHubの**「プッシュモデル」通知方式**は、オフライン中心の開発方式と相性が悪い
  • 非開発者ユーザー比率の高いプロジェクトでのコミュニティ運用ツール不足により開発者の疲弊が増えている
  • GitHubがLLMおよび生成AI中心にシフトする中、各サイトがLLMクローラーをブロックするためにJavaScriptウォールやブラウザフィンガープリント追跡を強化
    • その結果、Dilloユーザーのアクセスがブロックされる副作用が発生

自己ホスティングの構築

  • 既存のリポジトリサービスは単一点障害の排除と軽量運用を同時に満たすことができなかった
    • そのため直接サーバーを運用し、複数のミラーを保持することを決定した
  • dillo-browser.orgドメインを取得し、小型VPSサーバーを構築
    • 想定より安定的に運用されており、主にAIボットトラフィックを処理している
  • Gitフロントエンドとしてcgitを選択
    • C言語で書かれているためRAMとCPU使用量が少なく、JavaScriptなしで動作
    • Dilloで適切に表示されるようCSSを一部修正
    • https://git.dillo-browser.org/ でアクセス可能
  • バグトラッカーは独自開発の**『buggy』**を使用
    • MarkdownファイルをパースしてHTMLページを生成し、各バグはgitリポジトリに保存
    • コミット時にgit hookが自動でページを更新
    • オフライン編集可能で、セキュリティ脆弱性の懸念はない
    • https://bug.dillo-browser.org/ で確認可能
  • メーリングリストアーカイブは3つの外部サービスに分散保存され、将来的には自前のコピーを追加予定

ミラー設定

  • すべての重要データがgitリポジトリ形式で管理され、CodebergとSourcehutにミラーされている
    • 特定のリポジトリが停止しても低い移行コストで他のミラーに切り替え可能
  • 単一障害点はDNS(dillo-browser.org)
    • DNS喪失時にはメーリングリスト、Fediverse、IRCなどを使ってユーザーへ通知可能
    • データはgitに複製されているため重大な損失は発生しない

OpenPGP署名

  • 本ページは**Rodrigo Arias MalloのGPGキー(32E65EC501A1B6FDF8190D293EE6BA977EB2A253)**で署名されている
    • Dilloの最新リリースと同じキーで、GitHubアカウントにも登録されている
    • 署名ファイル(index.html.asc)は<link rel=signature>にリンクされている
  • OpenPGP署名はDNS喪失時でも信頼を維持可能
    • TLS証明書チェーンの代わりに署名ベースの信頼で所有権を証明
    • すべてのgitミラーに署名を含めることでデータ喪失耐性を強化

移行の進行と見通し

  • GitHubリポジトリは即時には削除されず、移行完了まで更新が継続される
    • 完了後はリポジトリを**「archived」状態**に変更し、公式サイトで通知する予定
    • 既存のコミットとリリースファイルは下位互換性維持のため保持
  • 新インフラは低コストと低消費電力で独立運用可能
    • 現在の寄付金とサーバー費用を基準に、最低3年間維持可能
    • 支援したい場合はLiberapayを通じてサポート可能 (https://liberapay.com/dillo/)

関連記事

1件のコメント

 
GN⁺ 2025-12-01
Hacker Newsの意見

  • 数年前からGitLabをセルフホストの代替として使ってきた。気に入ってはいるが、リソース消費が激しい
    最近はCodebergチームが作ったForgejoをテスト中だが、本当に素晴らしい
    最大の違いはメモリ使用量だ。GitLabはRuby on Railsベースなので複数のサービスが同時に動くが、ForgejoはGoで書かれた単一バイナリ構成だ
    GitLabは16GB VMのメモリを徐々に使い切ってしまうが、Forgejoはサーバーとrunnerを一緒に動かしても300MB程度しか使わない
    GraphQLはないが、REST APIで十分よさそうだ
    giteaとforgejoの違いはよく分からないが、Forgejoの比較ドキュメントを見ると、2022年にガバナンス問題でsoft forkされたようだ

    • うちのスタジオでは約50人のユーザーが毎日gitを使っているが、2年前にForgejoへ完全移行した
      Goベースのシンプルな構造なので、保守とコストが非常に少ない。社内ツールもForgejoの上に直接構築した
      オンプレミス運用なので、インターネットが切れても開発とCIが止まらない。パッケージマネージャーのキャッシュもサポートしており、依存関係の管理がしやすい
    • 保守のしやすさではgiteaが圧倒的だ。5年以上使っているが、アップグレードは新バージョンをpullしてデーモンを再起動するだけで終わる
      GitHubよりダウンタイムが10分の1だったし、その大半も計画メンテナンスだった
      GitHubの可用性のほうが高いと主張する投稿を見ると笑ってしまう
    • 個人プロジェクトなら、単にSSHサーバーとファイルシステムだけで十分だと思う
      新しいリポジトリを作るときはgit init --bareで終わり、バックアップも自動で回る
      一人で開発するなら、UIは別に必要ないと感じる
    • Forgejo Actionsの基本概念ドキュメントを見ると、CIシステムがよく整理されている
      GitHub ActionsよりGitLab式CIのほうがずっと良いと思う。GitHubは人気に後押しされて標準になったが、設計はいまひとつだ
    • もっとミニマルな代替を求めるならGerritもある。Javaアプリで外部DBへの依存がなく、設定とランタイム情報をgit repoに保存する
      共有ファイルシステムだけでもスケールとバックアップが簡単だ

  • 地域で数学クラブを運営しているが、子どもたちがLaTeXとPythonの課題を提出するときにForgejoを使っている
    ログイン管理やパスワード初期化が簡単なので、教育用途としても非常に有用だ

  • GitHubのプッシュ通知モデルが嫌で、自分で確認するときだけ更新を見たいという意見に共感する
    メールフィルタリングを使えば、プッシュ通知をプルモデルのように変えられる。専用フォルダに通知を集めておいて、必要なときだけ見ればよい

    • それでも不満ならGitHub UIの標準通知機能を使えばよい。正直、問題を見つけるための問題のようにも感じる

  • シンプルな**バグトラッカー「buggy」**を自作した人の話が興味深い。MarkdownをパースしてHTMLページを生成するCツールだという
    ハッカー精神が生きている

    • ただ、そういうアプローチを取る人はほとんどいない気がする。自分ならむしろ問題が増えそうだ
    • 長所と短所の両方があるアプローチだ

  • 「プッシュモデル」と「プルモデル」の違いを尋ねる質問があった

    • Source HutやLinuxカーネルのようなメールベースのワークフローを指しているようだ。IMAPでパッチをローカルに取り込めるので、オフラインでも作業できる
    • プッシュには「今すぐやれ」という時間的プレッシャーがあり、プルは自分で決めた周期で確認するという時間管理の違いだ

  • 今はいろいろなGitHub代替が噴き出している分散化（ディアスポラ）段階だと思う
    数か月以内に主流が一つに整理される可能性もある。有名企業や著名人が新しいプラットフォームを出せば、市場を主導するかもしれない

    • こうした流れは10年前からあった。以前はGitLabへ移る時期だったし、今でもGitHubの**発見性（discoverability）**は依然として突出している
      GitHubを離れるプロジェクトはごく少数なので、まだその段階ではないと思う
    • 開発者ごとに協業のやり方が違うので、一つのソリューションに収束するのは難しい
      むしろ**再分散化（re-decentralization）**が起きている。各自が自分の統制権、管轄、ワークフローに合ったforgeを選ぶ時代だ
    • 今後はGitHubのような中央集権型ではなく、**連合型（federation）**の構造に向かうのが目標だ。一つのエンティティに依存しなくなる
    • 重要なのは「一つの代替」を望むのか、それとも5年後にまた同じ状況を繰り返したいのかという問題だ
    • 私たちはまさにそれを試している。Tangledというインディー中心のコラボレーションプラットフォームを準備中で、まもなく大きな発表がある予定だ

  • DilloプロジェクトをTangledに招待したい → tangled.org

    • JavaScriptなしでもしっかり動くのが印象的だ
    • Git以外のバージョン管理システムにも対応してほしい

  • GitHubで最大の問題は遅くなった使い勝手だと思う

    • "more and more slow"という表現が自然なのか気になる。"slower and slower"のほうが一般的だろうか？
    • 以前は問題なかったが、最近はページ読み込みがあまりにも遅い。Reactだけが原因ではなさそうだ
      コード閲覧はgithub.devで済ませているが、PRとActionsは依然として遅くてもどかしい

  • VMにForgejoをインストールしたいなら、サーバーとrunnerをまとめてセットアップできるスクリプトを作ってある → easyforgejo

  • この話題に専門性はないが、興味深く読んだ
    バージョン管理システムを一つセットアップするだけでも、こんなに多くの要素があることに驚いた
    自分はFossilを使っているが、小規模組織で開発者・システム管理者・サポート担当を一人で兼任するときには、はるかにシンプルだ
    GitHubのdeploy keyの制約も不便だ。複数のアプリやサーバーを運用すると、鍵をそれぞれ別に設定しなければならず面倒だ