エンジニアリングノート
PlainAppのピアツーピア・アーキテクチャ、トランスポート設計、暗号化について、ソースコードに基づき深く掘り下げる。
DLNA キャスト：UPnP 送信側と受信側をスクラッチから構築する
PlainApp が DLNA/UPnP AV キャストを両方向で実装する方法：送信側として SOAP 経由でテレビをスキャン・制御し、受信側としてスマホ自体を UPnP MediaRenderer に変える——SSDP ディスカバリー、DIDL-Lite メタデータ、Range リクエスト対応のメディア配信、GENA イベントコールバック、送信元 IP による許可/拒否トラストモデルまで、すべて純粋な Kotlin Multiplatform で実現。
画面ミラーリング：低遅延キャスティングアーキテクチャ
本記事では、PlainApp の画面ミラーリングシステムのエンドツーエンド設計について解説します。Android が MediaCodec を介して H.264/Opus をハードウェアエンコードする仕組み、カスタムバイナリプロトコルで WebSocket 経由でフレームを転送する方法、Web 側が WebCodecs でデコードし WebGL2 で CPU コピーゼロでレンダリングする仕組み、ロス検出、画面回転処理、リモートタッチコントロール、そして MediaProjection のライフサイクル同期について取り上げます。
PlainApp セキュリティ詳解
PlainAppがローカルWi-Fiであなたのデータをどのように保護するか — オープンソースコードに基づく証拠とともに。
Wi-Fi Aware トランスポート設計 — 近隣ディスカバリとデータパス
本記事では、PlainApp がピアトランスポートのフォールバックチェーンの中間層として Wi-Fi Aware (NAN — Neighbor Awareness Networking) をどう使うかを説明します。LAN (同じサブネットの HTTPS) と BLE (最後の手段の GATT RPC) の間に位置します。Wi-Fi Aware は、2 台の PlainApp デバイスが異なる SSID、ゲスト vs IoT VLAN、あるいは Wi-Fi インフラストラクチャが全くない状況でも通信できるようにするもので — DHCP サーバーからの IP アドレスを一切必要としません。
BLE トランスポート設計 — メッセージとファイルダウンロード
本記事では、LAN も Wi-Fi Aware も利用できない場合に、PlainApp が Bluetooth Low Energy 経由でチャットメッセージをプッシュしファイルをダウンロードする方法を説明します。BLE は保証されたフォールバックです — 遅いものの、IP 接続性が一切なくても動作します。ワイヤーフォーマット、2 層チャンク設計、並行トラフィックの優先付け (とその限界)、そして各リクエスト後に接続を毎回破棄する理由を扱います。
ピア & チャネルチャットアーキテクチャ
本記事では、PlainApp のオフラインファーストなチャットがエンドツーエンドでどう動くかを説明します。UI のタップからピアトランスポート経由で相手デバイスに届くまでメッセージがたどる経路、グループチャネルが多数のメンバーにメッセージを fan-out する方法、そしてネットワークが消えたときにシステムがどうレジリエントさを保つかを扱います。ペアリング (2 台のデバイスをブートストラップする信頼と鍵交換) は別記事の Pairing Flow で扱っています。
ペアリングフロー
本記事では、2台の PlainApp デバイスが初めて信頼を確立する方法を説明します。デバイス同士がどのように発見し合い、鍵を交換し、その後のすべてのチャットメッセージ・ファイル転送・プレゼンス ping の暗号化に用いられる共通の ChaCha20 トランスポート鍵に到達するのか。この鍵を消費するチャットおよびチャネルのアーキテクチャは、別記事の Chat Architecture で扱っています。