[RFC] Native Datenherkunft & Faktenzuordnung für Discourse

Gemeinschaft
1

Hallo Discourse Community,

ich möchte mich vorstellen – ich bin Systemdesigner und erkunde derzeit das Discourse-Ökosystem. Ich gebe zu, dass ich noch kein Experte für die interne Architektur von Discourse bin, habe mich aber für diese Plattform für mein bevorstehendes Projekt entschieden, da sie über eine robuste Datenverwaltung und eine starke Community-Struktur verfügt.

Ich bereite derzeit einen Vorschlag vor, den ich meinem Vorgesetzten zur Genehmigung der Entwicklung vorlegen werde. Mein Ziel bei der Veröffentlichung hier ist es, Feedback, Einblicke oder konstruktive Kritik von Ihnen zu sammeln, die sich mit der Plattform am besten auskennen. Ihr Input wäre von unschätzbarem Wert, um mir zu helfen, dieses Konzept zu verfeinern, sicherzustellen, dass es mit den Best Practices von Discourse übereinstimmt, und letztendlich die Chancen auf eine Projektgenehmigung zu erhöhen.

Hinweis: Der folgende Inhalt ist recht detailliert. Vielen Dank im Voraus für jeden Rat, den Sie geben können.
Ich kann möglicherweise nicht sofort antworten, werde aber sicherstellen, dass ich jeden Kommentar so schnell wie möglich lese und darauf antworte.

Technische Spezifikation

Projekttitel: Discourse OriginGraph & Facto-Mapper
Untertitel: System zur nativen Nachverfolgung der Datenherkunft und Analyse der Zuverlässigkeit
Version: 1.0.0 (Vorschlag)

1. Zusammenfassung

In einer Ära der schnellen Informationsverbreitung zeichnen sich Diskussionsplattformen wie Discourse durch argumentationsbasierte Strukturierung aus, es mangelt ihnen jedoch an nativen Werkzeugen für die Analyse der Datenherkunft (Data Provenance Analysis) und die Visualisierung der strukturellen Entwicklung (Structural Evolution Visualization).

Discourse OriginGraph & Facto-Mapper ist ein Plugin, das entwickelt wurde, um Discourse von einem Standard-Diskussionsforum in eine Systematische Faktenprüfungs- & Intelligenzschicht umzuwandeln. Es nutzt die Graphentheorie, um die Informationsherkunft nachzuverfolgen, Beziehungen zu visualisieren und Zuverlässigkeitsmetriken zu berechnen, ohne die Kernbenutzererfahrung zu beeinträchtigen.

2. Technische Ziele

  • Rückverfolgbarkeit: Gerichteter azyklischer Graph (DAG) für Quelle → Erweiterung → Verifizierung
  • Visualisierung: Interaktive Facto-Karten in der Discourse-Benutzeroberfläche
  • Heuristische Analyse: Gewichtete, vertrauensbasierte Bewertung (kein binäres Wahr/Falsch)
  • Leistung: Asynchrone Verarbeitung über Sidekiq
  • Integration: Strikte Einhaltung der Discourse-Plugin-Architektur

3. Umfang der Arbeiten

3.1 Im Umfang enthalten (In-Scope)

  • Graphenbildung von Beziehungen innerhalb eines Themas (Antwort, Zitat, Erwähnung)
  • Signalextraktion aus gekochtem HTML
  • Konfigurierbare Herkunfts-/Stabilitätsbewertung
  • Steuerung über Discourse-Vertrauensstufen (Trust Levels)

3.2 Nicht im Umfang enthalten (Out-of-Scope)

  • NLP / LLM semantische Analyse (Phase 1)
  • Ersatz für die globale Suche
  • Cross-Instanz-Föderation

4. Systemarchitektur

4.1 Technologie-Stack

  • Backend: Ruby on Rails (Discourse Core), Sidekiq
  • Frontend: Ember.js, D3.js oder Cytoscape.js
  • Datenbank: PostgreSQL 13+, Redis
  • Datenaustausch: Interne JSON API

4.2 Konzeptionelles Architekturdiagramm

[Client: Ember.js]  <-- JSON -->  [Controller: Rails]
       |                                  |
(Interaktiver Graph)              (Anforderungsvalidierung)
       |                                  |
       v                                  v
[Visualisierungsbibliothek]     [Sidekiq Worker Pool]
                                          |
                                 +--------+--------+
                                 |                 |
                          [Graph Engine]     [Scoring Engine]
                                 |                 |
                                 +--------+--------+
                                          |
                                    [PostgreSQL]
                           (Kanten / Snapshots / Protokolle)

5. Datenmodell (Schema-Design)

5.1 Tabelle: provenance_edges

Spalte Typ Index Beschreibung
id BigInt PK Eindeutige Kanten-ID
topic_id Integer IDX Themene-Referenz
source_post_id Integer IDX Ursprungsknoten
target_post_id Integer IDX Zielknoten
relation_type Enum Antwort, Zitat, Referenz, Korrektur, Widerspruch
weight Float Kantenstärke
metadata JSONB Kontextdaten

5.2 Tabelle: facto_graph_snapshots

Spalte Typ Index Beschreibung
id BigInt PK Snapshot-ID
topic_id Integer UNIQUE Zugehöriges Thema
version Integer Graph-Version
graph_payload JSONB Knoten & Kanten
computed_at Datetime Erstellungszeitpunkt
is_public Boolean Sichtbarkeits-Flag

5.3 Redis-Schlüssel

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

6. Interne API-Spezifikation

POST /facto/analyze

  • Auth: TL1+
  • Parameter: topic_id, force_recalc
  • Antwort: 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. Algorithmen & Logik

7.1 Logik zur Signalextraktion

  • Alle Beiträge im Thema iterieren
  • reply_to_post_number → Antwortkante
  • Gekochtes HTML parsen → Zitatkante
  • Regex @usernameusername → Erwähnungskante

7.2 Bewertungsalgorithmus

Gewichtete Zentralität (PageRank-ähnlich):

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

Widerspruchskanten wenden Strafmultiplikatoren an.

8. UX / UI

  • Einstiegspunkt: Schaltfläche „Graph-Ansicht“ in der Themenkarte
  • Vollbild-Modal-Graph
  • Hover-Knoten: Beitragsausschnitt + Autor
  • Klick auf Knoten: Zum Beitrag scrollen
  • Filter: Kantentypen umschalten

9. Sicherheit & Governance

  • Ratenbegrenzung über Discourse RateLimiter
  • JSONB-Bereinigung zur Verhinderung von XSS
  • Private Themen erben Discourse ACL

10. Entwicklungs-Roadmap

  • Phase 1: MVP-Graphenextraktion + einfache Darstellung
  • Phase 2: Erweiterte Bewertung + Snapshot-Governance
  • Phase 3: Moderatoren-Annotationen + externe API
1 „Gefällt mir“