[RFC] Discourseのネイティブなデータ来歴と事実マッピング

コミュニティ
1

Hello Discourse Community,

システム設計者である私が、Discourseエコシステムを調査していることをご紹介します。Discourseの内部アーキテクチャの専門家ではないことは認めますが、堅牢なデータ管理と強力なコミュニティ構造のため、今後のプロジェクトでこのプラットフォームを選択しました。

現在、開発承認のために上司に提示する提案書を作成中です。ここで共有する目的は、プラットフォームを最もよく知っている皆様からフィードバック、洞察、または建設的な批判を収集することです。皆様からのインプットは、このコンセプトを洗練させ、Discourseのベストプラクティスに確実に準拠させ、最終的にプロジェクトの承認率を高める上で非常に貴重なものとなります。

注記: 以下の内容はかなり詳細です。ご提供いただけるアドバイスには前もって感謝いたします。
すぐに返信できないかもしれませんが、できるだけ早くすべてのコメントを読んで返信するようにいたします。

技術仕様

プロジェクト名: Discourse OriginGraph & Facto-Mapper
サブタイトル: ネイティブデータ来歴追跡＆信頼性分析システム
バージョン: 1.0.0 (提案)

1. エグゼクティブサマリー

急速な情報拡散の時代において、Discourseのようなディスカッションプラットフォームは、構造化された議論においては優れていますが、データ来歴分析および構造的進化の可視化のためのネイティブツールが不足しています。

Discourse OriginGraph & Facto-Mapperは、Discourseを標準的なディスカッションフォーラムから体系的な事実確認およびインテリジェンスレイヤーへと変革するために設計されたプラグインです。グラフ理論を活用して情報の系統を追跡し、関係性を可視化し、コアなユーザーエクスペリエンスを妨げることなく信頼性メトリクスを計算します。

2. 技術的目標

  • トレーサビリティ: ソース → 展開 → 検証のための有向非巡回グラフ (DAG)
  • 可視化: Discourse UIにおけるインタラクティブなFactoマップ
  • ヒューリスティック分析: 重み付けされた信頼度に基づくスコアリング（二値的な真/偽ではない）
  • パフォーマンス: Sidekiqを介した非同期処理
  • 統合: Discourseプラグインアーキテクチャへの厳格な準拠

3. 作業範囲

3.1 範囲内 (In-Scope)

  • トピック内関係グラフ化（返信、引用、メンション）
  • クック済みHTMLからのシグナル抽出
  • 設定可能な来歴/安定性スコアリング
  • Discourseの信頼度レベルによるガバナンス

3.2 範囲外 (Out-of-Scope)

  • NLP/LLMセマンティック分析（フェーズ1）
  • グローバル検索の置き換え
  • クロスインスタンスのフェデレーション

4. システムアーキテクチャ

4.1 テクノロジースタック

  • バックエンド: Ruby on Rails (Discourse Core), Sidekiq
  • フロントエンド: Ember.js, D3.js または Cytoscape.js
  • データベース: PostgreSQL 13+, Redis
  • データ交換: 内部JSON API

4.2 概念アーキテクチャ図

[クライアント: Ember.js]  <-- JSON -->  [コントローラ: Rails]
       |                                  |
(インタラクティブグラフ)              (リクエスト検証)
       |                                  |
       v                                  v
[ビジュアライザライブラリ]             [Sidekiqワーカープール]
                                          |
                                 +--------+--------+
                                 |                 |
                          [グラフエンジン]     [スコアリングエンジン]
                                 |                 |
                                 +--------+--------+
                                          |
                                    [PostgreSQL]
                           (エッジ / スナップショット / ログ)

5. データモデル（スキーマ設計）

5.1 テーブル: provenance_edges

カラム 型 インデックス 説明
id BigInt PK 一意のエッジID
topic_id Integer IDX トピック参照
source_post_id Integer IDX ソースノード
target_post_id Integer IDX ターゲットノード
relation_type Enum reply, quote, ref, correction, contradiction
weight Float エッジの強度
metadata JSONB コンテキストデータ

5.2 テーブル: facto_graph_snapshots

カラム 型 インデックス 説明
id BigInt PK スナップショットID
topic_id Integer UNIQUE 関連トピック
version Integer グラフのバージョン
graph_payload JSONB ノードとエッジ
computed_at Datetime 生成時刻
is_public Boolean 可視性フラグ

5.3 Redisキー

  • facto:quota:user:{id}:daily
  • facto:job:topic:{id}:status

6. 内部API仕様

POST /facto/analyze

  • 認証: TL1+
  • パラメータ: topic_id, force_recalc
  • レスポンス: job_id, status = queued

GET /facto/graph/:topic_id

version: 5
nodes:
  - id: 101
    group: source
    score: 0.8
edges:
  - source: 101
    target: 105
    type: verification

7. アルゴリズムとロジック

7.1 シグナル抽出ロジック

  • トピック内のすべての投稿を反復処理
  • reply_to_post_number → Replyエッジ
  • クック済みHTMLを解析 → Quoteエッジ
  • Regex @usernameusername → Mentionエッジ

7.2 スコアリングアルゴリズム

重み付けされた中心性（PageRankスタイル）：

Score(P) = (1 - d) + d × Σ((Score(Pi) × Weight(Ei,P)) / OutDegree(Pi))

Contradictionエッジはペナルティ乗数を適用します。

8. UX / UI

  • エントリーポイント: トピックマップ内のグラフ表示ボタン
  • フルスクリーンモーダルのグラフ
  • ノードをホバー: 投稿スニペット + 作成者
  • ノードをクリック: 投稿へスクロール
  • フィルター: エッジタイプを切り替え

9. セキュリティとガバナンス

  • Discourse RateLimiterによるレート制限
  • XSSを防ぐためのJSONBサニタイズ
  • プライベートトピックはDiscourse ACLを継承

10. 開発ロードマップ

  • フェーズ1: MVPグラフ抽出 + 基本レンダリング
  • フェーズ2: 高度なスコアリング + スナップショットガバナンス
  • フェーズ3: モデレーター注釈 + 外部API
「いいね！」 1