オフラインメッシュチャットにbitchatが選ばれる理由と類似OSS比較

停電やモバイル網の遮断で連絡が取れなくなる状況を想定したとき、「インターネットが無くても Bluetooth だけで動くチャットアプリを組織で採用できないか」という問いは、災害時通信・イベント現場・海外拠点でのオフライン運用など、さまざまな現場で繰り返し検討されてきました。

その候補として近年注目度が急上昇したのが permissionlesstech/bitchat です。Jack Dorsey 氏がリリースに関与したことで一般報道でも大きく取り上げられ、GitHub のスター数は 35,797（2026-08 時点）に達しています。ただし「オフラインで動くチャット OSS」というカテゴリだけを見れば、以前から Briar / Bridgefy / Meshtastic といった選択肢も存在しており、「なぜ bitchat を選ぶのか」「どこが劣後するのか」を整理せずに採用判断を下すのは危険です。

そこで本記事では、公式 README と Whitepaper v2.0 を主要出典として、bitchat の技術構造と設計思想を意思決定に必要な粒度で整理します。実行やビルドは行わず、あくまで一次資料に基づいた解説として、初見のエンジニアが「自プロジェクトに採用してよいか」を判断できる材料を提供することを目的とします。加えて、Whitepaper 開発者自身が明示している「メタデータ露出」「前方秘匿性の欠如」といった限界も隠さずに扱い、Briar・Bridgefy・Meshtastic との違いを 5 つの観点で比較します。

対象リポジトリの属性は執筆時点で archived=false、fork=false、private=false、disabled=false、ライセンスは Unlicense（パブリックドメイン相当）です。アーカイブ済みでもフォーク版でもなく、本家リポジトリが継続的に更新されているプロジェクト（最新プッシュ: 2026-08-16）である点をあらかじめ明示しておきます。

bitchat とは何か（オフラインメッシュチャットの位置づけ）

bitchat は permissionlesstech 組織が公開しているオープンソースの分散型メッセージングアプリです。README では "decentralized peer-to-peer messaging app with dual transport architecture" と位置づけられており、Bluetooth Low Energy（BLE）によるオフラインメッシュと、Nostr プロトコル経由のインターネットフォールバックという 2 つのトランスポートを組み合わせている点が特徴です。

公式サイトは bitchat.free にあり、標語は "It's the side-groupchat." です。アプリの入手経路として README は App Store 版 と Google Play 版、または「自身で検証したソースからのビルド」のみを推奨しています。README の「Getting a copy you can trust」節では、リポジトリがテイクダウン要求の対象となった経緯があるため、出所不明のミラー版は信頼しないよう明言されています。

リポジトリの基本プロファイルは次のとおりです。

数値は執筆時点で取得した GitHub API のメタデータに基づきます（permissionlesstech/bitchat リポジトリページ）。

コアな設計思想は「アカウント・電話番号・中央サーバーを一切要求しない」ことです。従来のメッセージングアプリが暗黙に前提としていた登録フロー・SMS 認証・サーバーサイド ID を排除し、端末側の鍵ペアだけでピア間通信を成立させます。想定ユースケースとしては、災害時通信・抗議活動・低接続地域での連絡・監視環境下での短距離コミュニケーションが README 上で例示されています。ライセンスがパブリックドメイン相当である点は、商用アプリへの組込みや改変再配布を検討する開発者にとって、法務レビューのハードルが低いという実務的なメリットにもつながります。

bitchat のアーキテクチャ（Bluetooth メッシュ + Nostr の二重トランスポート）

bitchat の技術的な独自性は「二重トランスポート」に集約されます。以下は主に WHITEPAPER v2.0 と docs/BLE-ARCHITECTURE-V3.md を出典として構造を整理します。

Bluetooth Low Energy メッシュ層

bitchat の一次トランスポートは Bluetooth Low Energy（BLE）を用いたアドホックメッシュです。すべての端末が GATT の central と peripheral の両ロールで振る舞い、事前ペアリングや Wi-Fi インフラ、SIM、アカウントを介さずに近傍ピアを自動発見します。メッセージは TTL 付きでマルチホップ中継され、Whitepaper では TTL の初期上限が 7 ホップ、密な近傍グラフでは 5 ホップに丸められる旨が明記されています。

重複中継を抑えるために、最新 1,000 件・5 分の LRU seen-set が用いられ、10〜220 ミリ秒のランダム jitter とファンアウトサブセッティングでフラッド攻撃・輻輳の緩和が図られています。パケットは約 469 バイト単位で断片化され、128 並列で組立、30 秒のタイムアウト、1 MiB の総量キャップが設けられています。BLE の帯域制約を前提に、多数のノード同士が中継しても爆発しないような設計が最初から組み込まれている、と理解できます。

Nostr プロトコル層

インターネットに到達できる環境では、bitchat は Nostr プロトコル を経由した相互通信にフォールバックします。Nostr は公開／秘密鍵ペアで署名した「イベント」をリレーサーバー群にブロードキャストするミニマルなプロトコルで、中央サーバーを持たないという特性が bitchat の思想と親和的です。

Whitepaper によれば、Nostr パスは主に「相互にお気に入り登録した信頼関係のあるピア間」の遠隔配送、および geohash 座標を用いたロケーションチャンネル（地域単位の公開チャットルーム）で利用されます。ネットワーク環境が敏感な場合の匿名化オプションとして、docs/TOR-INTEGRATION.md にある Tor 経由の Nostr 通信もサポートされています。ここで重要なのは、Nostr パスで使われる暗号エンベロープが後述するとおり NIP-17/44/59 とは非互換の独自形式である点です。

MessageRouter の役割

これら 2 つのトランスポートを切り替える中核が MessageRouter です。Whitepaper §2 の記述によれば、MessageRouter はまず生きているメッシュリンクを優先し、宛先ピアに到達できないと判断した場合に Nostr フォールバックへ切り替えます。どちらも即時配送に失敗した場合は、次章で扱う Store-and-Forward 系（Courier / Nostr Mailboxes 等）に配送を委譲します。

つまり利用者から見ると「オフラインでも動く」「地理的に離れた端末とも通信できる」「一時的に接続が切れても後で届く」の 3 つが単一のアプリで両立している構造であり、その裏には明確なフォールバック階層があります。

暗号化と Store-and-Forward の設計

セキュリティ設計は採用判断の中核となるため、Whitepaper §3〜§4 を主要出典として要点を整理します。

暗号化レイヤー（Noise Protocol と独自 private envelope）

• ライブセッション: Noise Protocol の XX パターン（Curve25519 / ChaCha20-Poly1305 / SHA-256）を使用します。相互認証と前方秘匿性を提供し、両者がリアルタイムに近傍にいるときの暗号化パスとして機能します。
• オフラインシール: Noise Protocol の X パターンを使用します。Whitepaper では「このパスは前方秘匿性を持たない」と明示されており、受信者の静的鍵が将来漏洩した場合、保存されている暗号文が復号可能になるトレードオフを受け入れる設計です。
• Nostr パス: kind-14 → kind-13 → kind-1059 の三重封緘構造を持つ独自 private-envelope が使われます。番号は Nostr の NIP-17 / NIP-44 / NIP-59 と同じですが、README と Whitepaper で明確に「これらの NIP とは互換ではない」と表明されており、Nostr リレー上を流れていても他の Nostr クライアントからは復号できません。相互運用性は bitchat クライアント同士に限定されます。

各端末は Curve25519 の Noise 静的鍵と Ed25519 署名鍵の 2 種類の長期鍵を OS の Keychain（iOS/macOS）に保管します。メッシュ上に露出するピア ID は Noise 静的鍵の SHA-256 フィンガープリント先頭 8 バイトで、セッションやリブート、再インストールをまたいで安定します。この安定性は「Favorites による相互信頼のリンクを維持しやすくする」という利便性のためですが、後述するメタデータ露出のリスクとも直結します。

Store-and-Forward の 4 機構

「相手がオフラインでも後から届く」という体験を成立させるために、bitchat は 4 種類の Store-and-Forward 機構を組み合わせています（Whitepaper §4）。

1. Sender Outbox: 端末側のローカルキュー。ピアごとに 100 メッセージ、24 時間の TTL で保持し、ChaChaPoly により封緘してディスクに永続化します。
2. Couriers: 未配送メッセージを「連絡可能な最大 3 名のピア」に委託する仕組みです。宛先はローテーションする 16 バイトの受信者タグで秘匿され、いわゆる「spray and wait」で拡散されます。Courier ピアはデータ本体を読むことはできませんが、意図的にドロップすることは可能なため、冗長コピーで緩和する設計です。
3. Public History（Gossip Sync）: 公開ブロードキャストの直近 1,000 件をキャッシュし、GCS（Golomb-coded set）フィルタを約 15 秒間隔で交換して差分を同期します。再同期ウィンドウは 6 時間です。
4. Nostr Mailboxes: BitChat の private envelope が Nostr リレー上でメールボックス的に待機し、24 時間のルックバックで再購読することで、後からオンラインになった受信者へ到達します。

なお応用層機能として、Whitepaper では「Panic Wipe」が用意されており、3 タップの緊急操作でアイデンティティ鍵・Favorites・保管中の Courier・封緘 outbox・公開履歴・メトリクスまでを一括で消去できると記されています。取材時・国境越え時などの物理的リスクを想定した機能で、単なる会話ログの削除より広範な破棄範囲になっている点は採用検討で見落とせないポイントです。

セキュリティモデルの限界と採用時の留意点

bitchat の Whitepaper で特に印象的なのは、開発者側が §8「Security Considerations」で自プロジェクトの弱点を明示的にリストアップしている点です。採用判断のためには、この節を無視して「E2E 暗号だから安全」と結論づけないことが重要です。

• メタデータ露出が最大の弱点: Whitepaper §8 は「メタデータはこの設計の最も弱い部分である」と自認しています。具体的には、(a) 8 バイトのピア ID がローテーションされず端末を長期に識別できてしまう、(b) Announcements（自己紹介ブロードキャスト）が静的鍵とニックネームを平文で搬送する、(c) 最大 10 件の近隣ピアリストが局所隣接グラフを露出する、(d) TTL の初期値からホップ距離を推定できる、といった観測性が挙げられています。ピア ID ローテーションは docs/PEER-ID-ROTATION.md で将来設計として議論されている段階です。
• オフラインシール／Nostr private envelope に前方秘匿性がない: 前述のとおり Noise X および Nostr パスは前方秘匿性を持ちません。受信者の静的鍵が将来的に流出した場合、リレーや Courier に残っていた暗号文は復号可能になります。ハイリスク環境で運用する場合、この特性を許容できるかが最初のふるいになります。
• Courier 経路はドロップに弱い: Courier ピアは暗号文しか読めませんが、悪意ある Courier がメッセージを意図的にドロップする可能性があります。冗長コピーで緩和されているとはいえ、Courier の到達保証は best-effort である点は明示しておくべきです。
• リレーノードは暗号文以上を見ない: 逆に Nostr リレー・BLE 中継ノードは暗号文しか観測できません。この保証は Whitepaper で明記されており、内容の秘匿性についてはメッセージ層で成立している設計です。

これらは「欠陥」というより「設計上のトレードオフを開示しているもの」であり、公式に明文化されているからこそ採用可否の議論が可能になります。詳細は WHITEPAPER.md §8 セクション を参照してください。

類似 OSS との比較（Briar・Bridgefy・Meshtastic）

「オフラインで動くチャット」というカテゴリで比較検討される代表的な OSS が Briar・Bridgefy・Meshtastic の 3 つです。5 つの観点で違いを整理します。

比較サマリテーブル

上表は公式リポジトリ・公式サイトおよび第三者の比較記事（Bluetooth Chat Apps Compared - bitchat.online, 2025-07 / Kaspersky "Chatting offline"）を突き合わせて整理した内容です。数値は運用条件により変動する目安値として扱ってください。

Briar との違い

Briar は Android 専用の匿名メッセージング OSS で、ライセンスは GNU AGPLv3 です。トランスポートは Bluetooth・ローカル Wi-Fi・Tor onion service の 3 系統を扱い、フォーラム機能やブログ機能を内蔵している点が bitchat との大きな差分です。ただし Briar の Bluetooth 通信は近距離同期にとどまり、「BLE ノードが中継してマルチホップで届ける」設計ではありません。iOS を含む複数プラットフォームで動かしたい場合や、明示的にマルチホップメッシュを組みたい場合は bitchat が候補になり、Android 単独完結で Tor onion まで押さえた匿名性を最優先するなら Briar が候補になります。

Bridgefy との違い

Bridgefy は同じく BLE ベースのメッシュメッセージング製品ですが、こちらはプロプライエタリで SDK 提供が中心です。既存アプリへの組込みに強く、香港やイランの抗議活動、大規模イベントでの利用実績が報道されてきました。一方、2020 年に暗号化上の脆弱性が研究者から指摘され、その後 Signal Protocol を導入した経緯があります（比較記事に詳しい経緯があります: bitchat.online の比較記事）。ソースが公開されておらず改変再配布ができないため、監査可能性を要件に含める場合には bitchat / Briar と選択肢が分かれます。

Meshtastic との違い

Meshtastic は LoRa（サブ GHz 無線）を用いる別カテゴリのメッシュで、専用の無線ハードウェアを必須とします。通信距離は BLE と桁違いで、条件が良ければ数 km〜十数 km に到達しますが、スループットは低くテキスト中心の運用が前提です。都市規模〜地方規模の広域カバレッジを、スマートフォン単体ではなく LoRa モジュールを配布する形で実現したい場合に強みを発揮します。bitchat と Meshtastic を橋渡しするサードパーティ meshtastic-bitchat-bridge のような取り組みも存在します。ハードウェア調達・電源設計・法規制対応（サブ GHz 帯の使用可否）まで含めた検討が必要になる点は、スマートフォン単体で完結する bitchat とは大きく性質が異なります。

bitchat が選ばれる場面

以上を踏まえると、bitchat の相対的な強みは次の 3 点に集約できます。

1. iOS/macOS を含むマルチプラットフォームでのマルチホップ BLE メッシュ: 同一構造の OSS で iOS を第一級に扱っているものは希少です。
2. Nostr フォールバックによる「メッシュを離れた到達」: 純粋な BLE メッシュに閉じず、地理的に離れたピア（相互お気に入り）にもインターネット経由で届く。
3. Unlicense によるライセンス上の可搬性: 商用改変・再配布の法務コストが低く、フォーク・組込を含む設計自由度が高い。

逆に、通信距離を数 km 単位で確保したい・SDK として自社アプリに組み込む契約サポートが欲しい・Android 単独で Tor onion を必須要件にしたい、といった要求がある場合は、それぞれ Meshtastic / Bridgefy / Briar の方が適合しやすくなります。

開発者視点で押さえておきたい採用可否チェック項目

自プロジェクトへの採用可否を判定する際には、以下の観点を先回りで検討することが推奨されます。動作検証を伴わない、ドキュメントベースでの判断材料としてまとめます。

• BLE 常時スキャンによるバッテリー消費: BLE のセントラル／ペリフェラル二重ロールを続けるため、モバイル OS のバックグラウンド制約と duty-cycle の調整方針を把握しておく必要があります。Whitepaper では「アダプティブなバッテリーモード」と「LZ4 メッセージ圧縮」が挙げられており、既定の実装で一定の最適化が行われていますが、常時稼働ユースケースでは実運用テストが不可欠です。

• ホップ数・パケットサイズの上限: TTL 最大 7 ホップ、密グラフでは 5 に丸められる仕様と、約 469 バイト単位の断片化・1 MiB のメディアキャップは、ユースケースの通信量と照らして事前に評価しておくべきポイントです。

• Nostr リレー依存とセルフホスト運用: インターネット到達時のフォールバックは公開 Nostr リレーを利用します。自組織内で完結させたい場合は、自前 Nostr リレーの運用可否と、Tor 統合を有効化するかを含めた検討が必要です（docs/TOR-INTEGRATION.md）。

• ビルドと配布: iOS/macOS は Xcode、just タスクランナー、SwiftPM を利用します。Android は別ビルドで管理されます。パブリックドメインとはいえ、独自ブランドで配布する際は最新の App Store / Google Play 各ガイドラインに沿った署名・提出手順を別途整備する必要があります。README にはビルド用の手順が抜粋されており、macOS でのビルドは以下のようにドキュメント化されています（引用は改変せず、出典を明記します）。

  xcodebuild -project bitchat.xcodeproj -scheme "bitchat (macOS)" \
    -configuration Debug CODE_SIGNING_ALLOWED=NO build
  

  出典: permissionlesstech/bitchat README。

• ビルドの検証手順: 出所検証は docs/VERIFYING-A-BUILD.md と docs/ARTI-BINARY-PROVENANCE.md にドキュメント化されています。「App Store 版」または「自身で検証したビルド」以外を推奨しない旨は README でも繰り返し記されています。ミラー版・第三者ビルドを組織内配布に使う場合は、この検証手順に沿って個別評価してから採用可否を判断してください。

• ライセンスの解釈: Unlicense はパブリックドメイン相当のリリースで、商用・改変・再配布のいずれも可能とされています。ただし依存ライブラリ側のライセンスは別途確認が必要で、Nostr 関連 SDK・暗号ライブラリの再配布条件は個別に精査する必要があります。

• セキュリティモデルの妥当性判断: 「メタデータ露出を許容できるか」「オフラインシールに前方秘匿性がなくてよいか」を採用の可否判断の中心に据えることを推奨します。ここが許容できる用途（例: 短時間のイベント連絡、災害時の一時的な連絡網、内部プロトタイプ）と、許容し難い用途（例: 長期的な内部告発、当局監視下での継続運用）を分けて考えるのが実務的です。

まとめと採用判断のロードマップ

bitchat は「アカウント・電話番号・中央サーバー不要」で動く分散型メッセージング OSS として設計・開発され、iOS/macOS/Android に対応した BLE マルチホップメッシュと、Nostr プロトコルによるインターネットフォールバックを両立している点が最大の特徴です。Unlicense によるパブリックドメイン相当のリリースで、GitHub リポジトリは archived=false / fork=false のまま活発に更新され続けており（最新プッシュ 2026-08-16、スター数 35,797）、Whitepaper v2.0 でセキュリティ上のトレードオフまで含めて公開されています。

一方で、メタデータ露出・オフラインシール／Nostr パスの前方秘匿性欠如・Courier のドロップ耐性といった限界も、公式に自認されています。これらのトレードオフを踏まえたうえで、次のようなロードマップで採用検討を進めるのが現実的です。

1. 要件整理: 通信距離・想定端末数・許容できるメタデータ露出範囲・前方秘匿性の必要性・法務要件（ライセンス互換性）を先に整理する。
2. 一次資料の確認: Whitepaper v2.0 の §2〜§4（アーキテクチャ）と §8（セキュリティ）、および docs/BLE-ARCHITECTURE-V3.md を読み込んでチーム内でレビューする。追加で全体像を俯瞰したい場合は DeepWiki の bitchat ページ が入口として便利です。
3. 類似 OSS との比較: 上述の比較テーブルを用途に照らし、Briar・Bridgefy・Meshtastic のうちより適合するものがないかを確認する。
4. ビルド検証と配布ポリシーの策定: 採用に進む場合は VERIFYING-A-BUILD.md に沿ってビルド出所検証のフローを内製化する。
5. プロトタイプの検討: 実装検討では、TTL・ホップ数・断片化上限・バッテリー消費・Nostr リレー依存など、事前に評価しておく設計項目をチェックリスト化する。

「無料で動くから採用する」という判断ではなく、「どの用途になら適合し、どこは代替 OSS の方がよいか」を切り分けたうえで採用可否を決めることが、bitchat のような分散型 OSS を業務・組織で扱うときの基本姿勢になります。

関連情報

分散型メッセージング・オフラインメッシュ・BLE を活用した業務用アプリの検討や、既存プロダクトへの技術評価・組込みをご検討中の方は、お問い合わせフォーム からご相談ください。要件整理の段階からご相談いただけます。

Swift / Kotlin / BLE / P2P など、分散型・オフライン耐性のあるアプリ開発に強みをお持ちのフリーランスエンジニアの方は、Workee で案件を探す から関連案件をご確認いただけます。