Durchgang durch ein Kommentarsystem: Threads, Moderationszustände und neu rendbarer Inhalt

Ziel

Nutzenden erlauben, verschachtelte Kommentare zu posten, die vor oder nach der Veröffentlichung moderiert, bearbeitet, gemeldet und entfernt werden können, während die gespeicherten Daten auch Jahre später noch sicher gerendert werden können.

Voraussetzungen

Eine Identität für Verfassende, ein Moderationsvorgehen (Vormoderation für neue Konten, Nachmoderation für vertrauenswürdige), sowie ein gewähltes Eingabeformat (Klartext oder eine Markdown-Teilmenge).

Schritte

1. Randbedingungen: gerendertes HTML nie als massgebliche Wahrheit speichern; das Entfernen eines Kommentars darf die darunterliegenden Antworten nicht zum Einsturz bringen; jede Moderationsaktion ist zuordenbar; Lesezugriffe sind paginiert und günstig.
2. Komponenten: eine Schreib-API mit Ratenbegrenzung je verfassender Person; der Speicher; ein Renderer, der Quelltext beim Lesen in HTML umwandelt und in einen verwerfbaren Cache legt; eine Moderationswarteschlange; ein Meldungs-Endpunkt; eine Prüfspur der Aktionen.
3. Datenmodell: comment(id, thread_id, parent_id, path, depth, author_id, body_source, status: pending|visible|hidden|removed, created_at, edited_at); comment_revision(comment_id, body_source, edited_at); report(comment_id, reporter_id, reason, at); moderation_action(comment_id, moderator_id, action, reason, at). Der materialisierte path aus Vorfahren-IDs mit einer Tiefenbegrenzung erlaubt günstige Teilbaum-Lesezugriffe; Kommentare der obersten Ebene nach (created_at, id) paginieren und Antworten seitenweise laden.
4. Rendering: body_source massgeblich halten und über eine bereinigende Pipeline rendern, deren Ausgabe nur ein Cache ist. Das OWASP-XSS-Cheat-Sheet hält fest, dass HTML-Sanitisierung gefährliches HTML entfernt und einen sicheren String zurückgibt, und dass Umgehungen von Sanitizern regelmässig entdeckt werden, sodass die Bibliothek gepatcht werden muss; gerendertes HTML zu speichern würde jede vergangene Umgehung dauerhaft in die Daten einfrieren.
5. Moderationszustände: pending ist nur für die verfassende Person selbst sichtbar; hidden behält den Knoten mit einem Platzhalter; removed durch die verfassende Person behält den Knoten, wenn er Kinder hat, und löscht ihn sonst. Die Zuteilung zur Warteschlange erfolgt nach Autorenvertrauen, Meldungsanzahl und einfachen Heuristiken (Links, wiederholter Text).
6. Fehlerbilder: Verhungern der Warteschlange (alterbasierte Priorität, Alarm bei Alter); koordiniertes Melden (Meldende nach Historie gewichten, einen Schwellenwert vor dem automatischen Ausblenden verlangen); sehr tiefe Threads (Tiefenbegrenzung und ein Link „diesen Thread fortsetzen“); Bearbeitungen nach der Freigabe (erneut in die Warteschlange, wenn sich der Text wesentlich geändert hat); eine verfassende Person löscht das Konto (die Person pseudonymisieren, den Knoten behalten).
7. Messen: Zeit in pending, Meldungen pro tausend Kommentare, Anteil nach einer Meldung ausgeblendet, Moderationsaktionen pro Tag, Renderer-Fehler.
8. Nicht zuerst: Abstimmungen und Rangfolge, Echtzeit-Aktualisierungen, ein Machine-Learning-Spam-Modell, Reputationsstufen, Rich Embeds, Reaktionen.

Erwartetes Ergebnis

Jeder sichtbare Kommentar lässt sich vom Quelltext bis zur Moderationsentscheidung zurückverfolgen, Threads behalten ihre Form, wenn Knoten entfernt werden, und ein Fix am Sanitizer wirkt beim nächsten Rendern auf die gesamte Historie.

Grenzen und Prüfbasis

Vorgeschlagenes Design, keine Messungen. Regeln zur Ausgabekodierung stehen im Artikel zu XSS; dieser Durchgang behandelt den Dienst darum herum.