[RFC] Discourse용 네이티브 데이터 출처 및 사실 매핑

Hello Discourse Community,

I’d like to introduce myself — I’m a system designer currently exploring the Discourse ecosystem. While I’m not yet an expert in Discourse’s internal architecture, I chose this platform for my upcoming project because of its strong data model, extensibility, and community-driven governance.

I’m currently preparing a proposal to present to my supervisor for development approval. By sharing this here, my goal is to gather feedback, insights, and constructive criticism from people who know Discourse best — particularly around feasibility, overlap with core features, and alignment with Discourse best practices.

Note: The proposal below is fairly detailed and technical.
I may not be able to reply immediately, but I will read and respond to every comment as soon as possible.


Plain-Language Overview (Quick Context)

The problem:
In many community discussions — especially around news, public policy, science, or controversial topics — claims are frequently challenged, corrected, or refined over time. While Discourse excels at discussion, it is still difficult to clearly see:

  • where a claim originally came from,
  • how it evolved through replies and quotes,
  • which posts support, correct, or contradict it,
  • and how confidence in that claim changes as the discussion grows.

The idea:
This project explores a plugin that turns discussion threads into transparent evidence graphs, helping communities perform collective fact-checking without relying on a single authority or binary “true/false” labels.

Instead of declaring facts, the system focuses on traceability, structure, and signals — allowing readers and moderators to judge credibility based on how information is sourced, challenged, and verified within the community.

Who might benefit:

  • Moderators & admins:
    • Supporting fair, evidence-based moderation decisions
    • Identifying corrections, disputes, and unstable claims more quickly
  • Fact-checkers & researchers:
    • Tracing claim lineage and verification paths inside discussions
  • Community members:
    • Engaging in debates with clearer context and shared references
  • Readers:
    • Understanding why a claim is trusted or disputed without reading every reply

[Facto Map]

This is an example of how I imagine the graph could look in practice.

It is intended for specialized use cases or for topics with overwhelming amounts of replies, where manually tracking, verifying, and understanding all arguments becomes impractical.

The Facto Map helps visualize claims, evidence, contradictions, and verification paths, making it easier for communities to fact-check, assess credibility, and conduct structured debates without losing context.

What follows is a technical specification / RFC-style proposal focused on architecture and feasibility.


Technical Specification

Project Title: Discourse OriginGraph & Facto-Mapper
Subtitle: Native Data Provenance Tracking & Reliability Analysis System
Version: 1.0.0 (Proposal)


1. Executive Summary

In an era of rapid information dissemination, discussion platforms like Discourse excel at structured argumentation but lack native tools for data provenance analysis, claim evolution tracking, and transparent fact-checking workflows.

Discourse OriginGraph & Facto-Mapper is a plugin designed to augment Discourse with a community-driven fact-mapping layer. Rather than enforcing absolute truth, it provides visual and statistical tools that help communities prove, challenge, and contextualize claims through structured discussion.

The system emphasizes:

  • traceability over authority,
  • confidence signals over verdicts,
  • and collective reasoning over centralized judgment.

2. Technical Objectives

  • Traceability:
    Directed Acyclic Graph (DAG) for Source → Expansion → Verification → Correction

  • Fact-Checking Support:
    Provide structural evidence for claims, rebuttals, and corrections without labeling content as true or false

  • Visualization:
    Interactive “Facto Maps” embedded directly in topic views

  • Heuristic Analysis:
    Weighted confidence-based scoring derived from discussion structure and verification patterns

  • Performance:
    Asynchronous processing via Sidekiq

  • Integration:
    Strict adherence to Discourse plugin architecture (Rails / Ember.js)


3. Scope of Work

3.1 In-Scope

  • Intra-topic relationship graphing (reply, quote, mention, correction, contradiction)
  • Signal extraction from cooked HTML and reply metadata
  • Configurable Origin / Stability / Dispute scores
  • Governance via Discourse Trust Levels
  • Moderator-visible fact-checking signals (non-authoritative)

3.2 Out-of-Scope

  • Automated truth classification (no true/false labels)
  • NLP / LLM semantic analysis (Phase 1)
  • Global search replacement
  • Cross-instance federation

4. System Architecture

4.1 Technology Stack

  • Backend: Ruby on Rails (Discourse Core), Sidekiq
  • Frontend: Ember.js, D3.js or Cytoscape.js
  • Database: PostgreSQL 13+, Redis
  • Data Interchange: Internal JSON API

4.2 Conceptual Architecture Diagram

[Client: Ember.js]  <-- JSON -->  [Controller: Rails]
       |                                  |
(Interactive Facto Map)           (Request Validation)
       |                                  |
       v                                  v
[Visualizer Library]             [Sidekiq Worker Pool]
                                          |
                                 +--------+--------+
                                 |                 |
                          [Graph Engine]     [Scoring Engine]
                                 |                 |
                                 +--------+--------+
                                          |
                                    [PostgreSQL]
                           (Edges / Snapshots / Logs)

5. Data Model (Schema Design)

5.1 Table: provenance_edges

Column Type Index Description
id BigInt PK Unique edge ID
topic_id Integer IDX Topic reference
source_post_id Integer IDX Origin node
target_post_id Integer IDX Destination node
relation_type Enum reply, quote, ref, correction, contradiction
weight Float Edge strength
metadata JSONB Context data

5.2 Table: facto_graph_snapshots

Column Type Index Description
id BigInt PK Snapshot ID
topic_id Integer UNIQUE Associated topic
version Integer Graph version
graph_payload JSONB Nodes & edges
computed_at Datetime Generated time
is_public Boolean Visibility flag

5.3 Redis Keys

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

6. Internal API Specification

POST /facto/analyze

  • Auth: TL1+
  • Params: topic_id, force_recalc
  • Response: 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. Algorithms & Logic

7.1 Signal Extraction Logic

  • Iterate all posts in topic
  • reply_to_post_number → Reply edge
  • Parse cooked HTML → Quote edge
  • Regex @username → Mention edge
  • Moderator annotations → Correction / Contradiction edges

7.2 Scoring Algorithm

Weighted centrality (PageRank-style):

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

Negative or contradictory edges apply penalty multipliers rather than binary rejection.


8. UX / UI

  • Entry point: “Graph View” button in topic map
  • Fullscreen modal Facto Map
  • Hover node: post snippet + author + confidence signals
  • Click node: scroll to post
  • Filters: show/hide corrections, contradictions, or only verified paths

9. Security & Governance

  • Rate limiting via Discourse RateLimiter
  • JSONB sanitization to prevent XSS
  • Private topics inherit Discourse ACL
  • No automated moderation actions — signals are advisory only

10. Development Roadmap

  • Phase 1: MVP graph extraction + basic visualization
  • Phase 2: Advanced confidence scoring + moderator annotations
  • Phase 3: External fact-checking API & research exports
2개의 좋아요

안녕하세요 @Thefacto - 이 프로젝트를 시작하셨나요? 혹은 제작하셨나요?
"provenance"라는 단어로 검색해 보았는데, Discourse가 C2PA 또는 유사한 기술에 대해 무엇을 제공하고 있는지(제공할 수 있는지/하고 있는지) 알아보고 싶기 때문입니다.

여기서 (사실 지도에 초점을 맞추고 있지만) 부분적으로 구축해 두셨을 수 있는 중요한 측면은 다음과 같습니다…

  • 매니페스트 생성
  • 그 후의 암호화 서명
  • 어떤 형태의 임베딩/워터마킹
  • 그리고 배포(에셋과 함께)
  • 마지막으로 검증을 위한 표시

여기서 무엇을 구축하려는 건지 아직 완전히 파악하지 못했을 수도 있습니다. 하지만 "콘텐츠 출처(content provenance)"라는 주제는 최우선 과제입니다.

OP가 이 논문을 살펴보고 생각을 공유해 주실지 궁금합니다.

https://www.sciencedirect.com/science/article/pii/S0749597825000172

OP의 주제와 너무 관련이 적다고 생각되신다면, 새 게시물로 옮기겠습니다.
감사합니다.

1개의 좋아요