Guia de design de um sistema de comentários: threads, estados de moderação e conteúdo re-renderizável

Objetivo

Permitir que usuários publiquem comentários em threads que possam ser moderados antes ou depois da publicação, editados, denunciados e removidos, mantendo os dados armazenados seguros para renderização mesmo anos depois.

Pré-requisitos

Uma identidade para os autores, uma política de moderação (pré-moderação para contas novas, pós-moderação para contas confiáveis) e um formato de entrada definido (texto simples ou um subconjunto de Markdown).

Passos

1. Restrições: nunca armazenar o HTML renderizado como fonte da verdade; remover um comentário não pode fazer as respostas abaixo dele desaparecerem; toda ação de moderação deve ser atribuível a alguém; as leituras são paginadas e baratas.
2. Componentes: uma API de escrita com limites de taxa por autor; o armazenamento; um renderizador que converte o texto-fonte em HTML no momento da leitura, gravando em um cache que pode ser descartado; uma fila de moderação; um endpoint de denúncias; uma auditoria das ações.
3. Modelo de dados: 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). O path materializado, com os ids dos ancestrais e um limite de profundidade, permite ler subárvores a baixo custo; os comentários de primeiro nível são paginados por (created_at, id) e as respostas são carregadas por página.
4. Renderização: manter body_source como fonte autoritativa e renderizar por meio de um pipeline de sanitização cuja saída serve apenas como cache. O OWASP XSS cheat sheet afirma que a sanitização de HTML remove HTML perigoso e devolve uma string segura, e que bypasses de sanitizadores são descobertos regularmente, de modo que a biblioteca precisa ser mantida atualizada com patches; armazenar o HTML renderizado cristalizaria nos dados todos os bypasses do passado.
5. Estados de moderação: pending é visível apenas para o próprio autor; hidden mantém o nó com um texto substituto; removed pelo autor mantém o nó se ele tiver filhos e o exclui caso contrário. O encaminhamento para a fila considera a confiança no autor, o número de denúncias e heurísticas simples (links, texto repetido).
6. Modos de falha: fila parada (prioridade por idade e alerta quando itens envelhecem); denúncias em massa coordenadas (ponderar os denunciantes pelo histórico e exigir um limite mínimo antes de ocultar automaticamente); threads muito profundas (limite de profundidade e um link "continuar esta thread"); edições após a aprovação (voltar para a fila quando o texto mudou de forma relevante); autor que exclui a conta (pseudonimizar o autor e manter o nó).
7. Medir: tempo em pending, denúncias por mil comentários, proporção ocultada após uma denúncia, ações de moderadores por dia, erros do renderizador.
8. Não são prioridade: votos e ranking, atualizações em tempo real, um modelo de machine learning contra spam, níveis de reputação, embeds ricos, reações.

Resultado esperado

Todo comentário visível pode ser rastreado do texto-fonte até uma decisão de moderação, as threads mantêm sua estrutura quando nós são removidos, e uma correção no sanitizador vale para todo o histórico na próxima renderização.

Limites e base de verificação

Design proposto, sem medições. As regras de codificação de saída estão no artigo sobre XSS; este guia cobre o serviço ao redor delas.