Skip to content

README.ja.md

Latest commit

 

History

History
309 lines (228 loc) · 18.3 KB

README.ja.md

File metadata and controls

309 lines (228 loc) · 18.3 KB
Raw
EdgeChat

Cloudflare フルスタックで作られたモダンなチーム向けチャットシステム

アカウント体系 · 公開/プライベートグループ · ダイレクトメッセージ · リアルタイムメッセージ · ファイルアップロード · 管理ダッシュボード

license stars forks issues last commit

Vue 3 Cloudflare Workers Hono Durable Objects GPL-3.0-or-later Telegram Bridge

中文 · English · 日本語 · オンラインデモ · プロジェクトドキュメント · Telegram コミュニティ

これは 1,000万人未満のチームに最適な Cloudflare チャットルームかもしれません


EdgeChat は Cloudflare 上にデプロイするチーム向けチャットシステムです。アカウント体系、公開グループ、プライベートグループ、ダイレクトメッセージ、リアルタイムメッセージ、ファイルアップロード、管理ダッシュボードをひととおり揃えています。目標は明確です。Cloudflare エコシステムの中で、できるだけ低い運用コストで、そのまま本番投入できるサイト内 IM を動かすことです。

目次

インターフェースプレビュー

チャット画面 管理ダッシュボード
EdgeChat チャット画面プレビュー EdgeChat 管理ダッシュボードプレビュー

オンラインデモ

edgechat-demo.wcjxxgaq.workers.dev

デモサイトは本番プロジェクトの Vue ページ、ルーティング、状態管理、リアルタイムメッセージのロジックをそのまま再利用していますが、すべての API・WebSocket・ファイルアップロード・Telegram のやり取りはブラウザのメモリ内でシミュレーションされます。ページをリロードするか、右上の「デモデータをリセット」をクリックすると初期状態に戻ります。本番 Worker には一切アクセスせず、D1・KV・R2 への書き込みも発生しません。

注目機能：Telegram 双方向メッセージブリッジ

管理者は EdgeChat 内の任意のグループを Telegram グループにバインドできます。バインドすると、Telegram Bot 経由で両側のメッセージが双方向にリアルタイム転送されます。EdgeChat のメンバーが送信したメッセージは Telegram グループにも表示され、Telegram グループのメッセージも EdgeChat に表示されます。両側のメンバーはあたかも同じグループで会話しているかのように使えるため、アプリを切り替えたりグループを二重に作ったりする必要はまったくありません。

EdgeChat と Telegram の双方向メッセージブリッジのデモ
リアルタイムでシームレスに転送、双方向同期

なぜ EdgeChat なのか

EdgeChat 自前ホスティングの Rocket.Chat / Mattermost 商用 SaaS IM
デプロイコスト Cloudflare の無料枠で運用可能 常駐サーバー / コンテナが必要 人数単位のサブスク課金
運用負担 サーバー管理不要、Serverless データベースやキャッシュを自前で運用 運用不要だが制御不能
データの帰属 完全に自分の Cloudflare アカウント内 完全に自前で保持 データは第三者に
導入方法 GitHub Actions でワンクリック自動デプロイ 手動 / Docker Compose 登録するだけ

この比較表はあくまで大まかな選定の参考です。実際に合うかどうかはチームの規模やニーズ次第です。Issue での議論・ご指摘をお待ちしています。

機能

💬 メッセージと会話

  • 公開グループ、プライベートグループ、ダイレクトメッセージの会話に対応
  • Telegram グループ双方向メッセージブリッジ：1 つの Bot で両側のメンバーをつなぐ
  • リアルタイムメッセージ、履歴のページング、ファイルメッセージ
  • ファイルアップロードとアバター管理
  • 期限切れメッセージの定期ハード削除に対応

🔐 プライバシーとセキュリティ

  • 新しく書き込まれたメッセージと新しくアップロードされた添付ファイルは AES-256-GCM でサーバー側暗号化。履歴データへの一括バックフィルは行わない
  • 管理ダッシュボードにはグループやダイレクトメッセージの本文を閲覧する入口を用意しない
  • ユーザーは管理者が作成し、自己登録は開放しない

🛠 管理ダッシュボード

  • ダッシュボード、ユーザー管理、登録招待、サイト設定のファーストレベルナビゲーション
  • ブラウザからソースリポジトリと直接比較し、現在のデプロイに更新があるか確認

🎨 体験

  • モダンな Liquid Glass スタイルのインターフェース
  • モバイル対応、基本的なアクセシビリティ対応

技術スタック

frontend backend
realtime d1 kv r2
deploy

Telegram コミュニティ

Telegram コミュニティ にぜひご参加ください。他のユーザーや開発者と交流し、フィードバックを共有し、プロジェクトの最新情報を受け取れます。

デプロイ

GitHub Actions 自動デプロイ（推奨）

GitHub Actions でのデプロイを優先的に推奨します。長期的なメンテナンスと本番環境の更新に適しています。リポジトリには .github/workflows/deploy-worker.yml が用意されており、master または main へのプッシュ、あるいは手動の workflow_dispatch トリガーで自動デプロイが実行されます。

🔐 プライバシーとサーバー側暗号化の説明（クリックで展開）

GitHub Actions がサーバー側暗号化の Worker Secrets を管理します。初回デプロイ時に、対象 Worker に暗号化 Secret が存在しない場合、ワークフローがランダムな 32 バイトの AES キーを自動生成し、独立したバージョン管理された Secret として注入して、現在の active key ID を記録します。以降の通常デプロイではこれらの Secret の存在を確認するだけで、再生成・上書き・ローテーションは行いません。本番環境に既存の EDGECHAT_ENCRYPTION_KEYRING JSON キーリングもそのまま保持され、引き続き互換性があります。

デプロイ後に新しく書き込まれたメッセージ本文と新しくアップロードされた添付ファイルは自動的に暗号化されます。過去の D1 メッセージと R2 添付ファイルはそのまま残り、読み取り時は過去の平文と新しい暗号文の両方に対応します。Cron や定期タスク、デプロイスクリプトで全履歴データを一括暗号化することはありません。

キーを手動で指定する場合は、以下の形式で EDGECHAT_ENCRYPTION_KEYRING という名前の GitHub Repository Secret を作成します：

{"activeKeyId":"v1","keys":{"v1":"BASE64_ENCODED_32_BYTE_KEY"}}

初回デプロイではこの値がそのまま採用されます。既存の Worker を自動で段階的にローテーションする場合は、Deploy Worker を手動で実行し rotate_encryption_key にチェックを入れます。ワークフローはバージョン管理されたキー Secret を 1 つ追加して active key ID を新しいバージョンに切り替えるだけで、すべての古い Secret と旧 JSON キーリングは変わりません。新しいメッセージは新しい active key を使用し、古い暗号文は引き続きそれぞれのエンベロープ内の key ID で復号されます。

apply_encryption_keyring は予備の手動上書き用エントリです。使用する場合は、Repository Secret に完全な JSON キーリングが必要で、keys には過去の暗号文から参照されている古い key ID をすべて残し、新しい key を追加して activeKeyId を更新します。古い key を削除すると、対応する過去の暗号文が永久に読み取れなくなります。apply_encryption_keyring と rotate_encryption_key を同じ実行で同時に有効にすることはできません。

これはサーバー側の保存時暗号化であり、エンドツーエンド暗号化ではありません。Worker はセッション権限チェックを通過した後に内容を復号するため、Cloudflare Worker の実行環境とキーを管理するデプロイ側は依然として信頼境界の内側にあります。それに伴うプライバシー調整として、管理ダッシュボードのメッセージ検索と完全な会話閲覧ページおよびその API は削除済みです。管理者は引き続きメッセージ数などの集計統計を確認できます。

手動デプロイ / Docker

手動デプロイと Docker の説明をクリックして展開

ローカルで手動デプロイしたい場合は、手順・リソース準備・注意事項の詳細をドキュメントサイトでご覧ください：

クイックスタート

# 依存関係のインストール
npm install

# フロントエンド開発
npm run dev:frontend

# フロントエンドのみのデモ（独立したポートとビルドディレクトリ）
npm run dev:demo

# ローカルビルド
npm run build

# ローカル手動デプロイ
npm run deploy
その他のスクリプトの説明（demo ビルド / デプロイ、CI 環境変数） 
# demo を独立ビルド
npm run build:demo

# 独立した demo Worker をデプロイ
npm run deploy:demo

demo は wrangler.demo.toml と .github/workflows/deploy-demo.yml を使用し、Worker 名は edgechat-demo です。GitHub Actions は手動トリガーのみ対応で、DEMO_CLOUDFLARE_ACCOUNT_ID と DEMO_CLOUDFLARE_API_TOKEN を読み取ります。既存の本番デプロイワークフローは変更されません。

非対話環境でデプロイする場合は、事前に CLOUDFLARE_API_TOKEN を設定する必要があります。

管理画面の更新チェックは、ビルド時に現在の GitHub リポジトリ・ブランチ・コミットを自動記録します。正確な結果を得るには、手動デプロイは Git リポジトリ内で、すでにプッシュ済みのクリーンなコミットを基にビルドしてください。ブラウザから GitHub Compare API を直接呼び出せるよう、ソースリポジトリは公開のままにする必要があります。このプロセスで定期タスクが作成されることはありません。

PowerShell の例：

$env:CLOUDFLARE_API_TOKEN = "your-token"
npm run deploy

プロジェクト構成

ディレクトリツリーをクリックして展開 
edgechat/
├─ assets/
│  └─ previews/
│     ├─ chat-home.png
│     └─ admin-dashboard.png
├─ frontend/
│  ├─ src/
│  │  ├─ api.js
│  │  ├─ router.js
│  │  ├─ store.js
│  │  ├─ ws.js
│  │  ├─ runtime.js
│  │  ├─ demo/
│  │  ├─ styles.css
│  │  ├─ components/ui/
│  │  └─ pages/
│  ├─ vite.config.js
│  └─ vite.demo.config.js
├─ worker/
│  ├─ schema.sql
│  ├─ migrations/
│  └─ src/
│     ├─ index.js
│     ├─ auth.js
│     ├─ db.js
│     ├─ middleware.js
│     ├─ utils.js
│     ├─ api/
│     └─ do/
├─ wrangler.toml
├─ wrangler.demo.toml
├─ package.json
├─ README.md
├─ README.en.md
├─ README.ja.md
└─ LICENSE

実装の詳細は TECHNICAL.md とドキュメントサイトをご覧ください：https://echat.azora.top/

コントリビューション

Issue と Pull Request を歓迎します。EdgeChat を一緒に育てていきましょう。

プロジェクトに貢献してくださったすべての皆様に感謝します：

Contributors

Star History

Star History Chart

スターをよろしくお願いします！

ライセンス

このプロジェクトは GNU GPL v3.0 or later を採用しています。

本プロジェクトの使用・変更・再配布は自由です。変更版を再配布する場合は、対応するソースコードを引き続き提供し、GPL 互換を維持する必要があります。

謝辞

linux do による本プロジェクトのプロモーションへの貢献に感謝します。