rfc-4 · aup

acceptable use policy

versão 0.1 · atualizado 2026-04-16 · status: publicado


§1

escopo

Este documento é a forma normativa da Acceptable Use Policy (AUP) do protocolo Aevia. Define quais categorias de conteúdo não são amplificadas, como thresholds operacionais aplicam essas restrições, e os procedimentos legais obrigatórios. A página UI em /aup é a forma legível por humanos; este RFC é a referência canônica.

MUST, SHOULD, MAY seguem RFC 2119.

§2

princípio da separação

Esta AUP governa distribuição, não persistência. Conteúdo que viola §3 permanece no IPFS e no Content Registry; o que é revogado é o subsídio do persistence pool, o surface em feed curado, e o peso em ranking. Implementações conformes MUST preservar recuperabilidade por CID de todo conteúdo canonicamente assinado, independentemente de sua elegibilidade editorial.

Este princípio é load-bearing para a imunidade da Aevia LLC como intermediário sob 47 U.S.C. §230. Ao modular distribuição com critério público, a Aevia exerce moderação protegida pela section 230(c)(2)(a); ao não suprimir bits, não se torna publisher do conteúdo alheio.

§3

exclusões normativas

Implementações conformes MUST excluir as categorias abaixo de subsídio e de feed curado. Categorias marcadas com [ABSOLUTE] adicionalmente MUST ser removidas de indexação e reportadas conforme §5.

  • [a] pornografia e conteúdo sexualmente explícito.
  • [b] [ABSOLUTE] qualquer sexualização de menores — tolerância zero absoluta; reporte NCMEC CyberTipline obrigatório conforme 18 U.S.C. §2258A.
  • [c] [ABSOLUTE] conteúdo íntimo não consentido (NCII), incluindo deepfakes sexualizados — conforme SHIELD Act (15 U.S.C. §6851).
  • [d] apologia celebratória de violência, terrorismo ou dano físico a pessoas.
  • [e] apologia celebratória de aborto.
  • [f] ocultismo, satanismo e feitiçaria como prática.
  • [g] apologia de uso recreativo de drogas ilícitas.
  • [h] discurso de ódio acionável contra qualquer grupo — incluindo cristãos, judeus, muçulmanos, ateus e quaisquer outros.
§4

thresholds de aplicação

Decisões operacionais são tomadas via Risk Score (RFC-6). Esta AUP especifica os thresholds:

  • θ_subsidy = 0.5 — CIDs com R(c) ≥ 0.5 SÃO excluídos de compensação do persistence pool.
  • θ_feed = 0.3 — CIDs com R(c) ≥ 0.3 SÃO excluídos do feed curado e de ranking em clientes Aevia.
  • conteúdo marcado [ABSOLUTE] MUST ter R_values = 1 independentemente do classificador, e adicionalmente MUST ser desindexado e (para [b]) escalado à NCMEC em até 24 horas da detecção.

Thresholds e pesos da fórmula são parâmetros de protocolo sujeitos a aprovação do Conselho (RFC-7).

§5

procedimentos legais

Implementações operando como intermediário sob jurisdição US/EEA MUST:

  • DMCA §512 — designar agente junto ao U.S. Copyright Office, aceitar notificações com elementos exigidos por §512(c)(3), respeitar janela de contra-notificação de 10–14 dias úteis, aplicar política de strikes (1º=aviso, 2º=revisão manual + suspensão, 3º=terminação).
  • DSA art. 16 — operar canal notice-and-action, responder em até 7 dias úteis com justificativa fundamentada quando a decisão for desfavorável ao notificante.
  • NCMEC CyberTipline — reportar CSAM aparente em até 24h; preservar material 90 dias conforme §2258A(h); não revisar além do mínimo para reporte.
  • OFAC — não prover serviço a residentes/entidades em jurisdições sob sanções compreensivas; consultar SDN List.
§6

apelação

Criadores cujo conteúdo foi restringido MAY solicitar revisão por júri conforme RFC-7. A solicitação MUST:

  • ser enviada em até 30 dias após a notificação de restrição;
  • conter o CID em disputa e a justificativa de que a classificação sob §3 é incorreta;
  • ser assinada pela chave do criador (RFC-3) para evitar abuso por terceiros.

Decisões de apelação MUST ser publicadas no Trust Ledger com justificativa textual. Reclassificações resultam em atualização dos componentes R_abuse e R_values do Risk Score.

Categorias [ABSOLUTE] NÃO admitem apelação. Esta restrição é deliberada.

§7

considerações de segurança

  • flag spam: reporters maliciosos podem tentar deprimir R_abuse via reportes em massa. Implementações SHOULD ponderar por reputação do reporter e exigir custo mínimo por reporte.
  • classificador adversarial: conteúdo pode ser construído para evadir classificadores de R_values. Revisão manual por júri é o recurso de último estágio.
  • captura regulatória: tentativa de pressão governamental para ampliar a lista de §3 MUST passar pelo Conselho e pelo Trust Ledger — sem via unilateral pela Aevia LLC.
§8

referências

  1. IETF RFC 2119 — Key words for RFCs
  2. 17 U.S.C. §512 — DMCA safe harbor
  3. 47 U.S.C. §230 — Section 230 intermediary immunity
  4. 18 U.S.C. §2258A — NCMEC reporting requirements
  5. 15 U.S.C. §6851 — SHIELD Act
  6. Regulation (EU) 2022/2065 — Digital Services Act
  7. RFC-6 — Risk Score (draft)
  8. RFC-7 — Moderation and Ecumenical Jury (draft)
rfc-4 · aup · aevia.network · aevia.network