12 RECURSOS · PÓS-QUÂNTICO · FIPS 203/204

Privacidade é um direito, não um recurso.
É uma categoria nova de mensageria.

mytho.chat tem tudo que os grandes têm em criptografia — e 12 recursos que eles não fazem: identidades múltiplas, mensagens com timer próprio, salas efêmeras locais, voice anônima, stories em comunidades privadas, comércio P2P com escrow embutido, pagamentos sem trocar dados bancários no chat, tradução automática e mais.

12
recursos exclusivos
identidades por instalação
5min — 24h
TTL configurável
0
bytes legíveis no servidor
🎭
modo deniable em qualquer chat
O QUE VOCÊ SÓ FAZ AQUI

12 recursos. Todos arquiteturalmente impossíveis
nos concorrentes.

Cada um aproveita uma propriedade que WhatsApp e Telegram não têm — porque exigem telefone e armazenam grafo social. Aqui, o servidor entrega bytes que não sabe abrir.

Recurso 01

Identidades múltiplas

N personas Dilithium independentes na mesma instalação. Trabalho, família, contexto sensível — cada uma com chave própria. Switch reconecta como peer novo. Servidor não correlaciona.

Ter uma identidade para o trabalho, outra para a família, outra para o que ninguém precisa saber.

DilithiumPoW 5spush só ativa
leia mais
Recurso 02

Auto-destruct granular

5 políticas por mensagem, não por chat. View-once · timer após abrir · timer no recipient · TTL fixo · revogável. Screenshot detect avisa o autor.

Mandar uma mensagem que se autodestrói em 30 segundos depois de aberta — só esta, não todo o chat.

5 policiesrevokescreenshot alert
leia mais
Recurso 03

Salas efêmeras locais

Código 6-char + QR + broadcast Bluetooth/mDNS. Descobertas por proximidade. Anônimas por padrão. Auto-destroem no fim do evento (max 8h).

Criar uma sala para o show, evento ou protesto. Os contatos somem quando acaba.

QRBLEmax 100
leia mais
Recurso 04

Voice rooms anônimos

WebRTC mesh P2P (max 12). Servidor não passa pelo áudio — só signaling. Gravação impossível server-side. Participantes são "ANÔNIMO #032".

Participar de uma sala de voz anônima de apoio sem virar registro permanente.

WebRTC P2PSTUN públicosem TURN-logs
leia mais
Recurso 05

Modo deniable

Mensagens com MAC simétrico (sem Dilithium). Recipient sabe que veio de você, mas não pode provar a terceiros — porque ele também tem a chave e poderia forjar. OTR/MLS deniability.

Conversar em modo deniable: ninguém pode provar que foi você quem disse aquilo.

MAC-onlyOTR/MLSdefesa legal
leia mais
Recurso 06

Stories em salas privadas

Stories estilo Instagram, mas só membros da sala/esfera veem. Anônimo opcional. TTL 1min–24h. Sem feed público. Sem algoritmo. Sem followers.

Compartilhar um story que só sua comunidade privada vê — não a internet.

por-salaanon opcionalsem reactions
leia mais
Recurso 07

Lightning · pagamentos P2P

Passthrough não-custodial. BOLT-11 invoice cifrada E2E, deep link abre wallet do usuário. Server nunca toca saldo, chave ou preimage.

Pagar Lightning P2P sem intermediário, direto no chat.

BOLT-11não-custodialE2E
leia mais
Recurso 08

Auto-idioma + tradução

Cada sala detecta seu idioma dominante a partir das últimas 50 mensagens. Toggles de leitura e escrita persistidos uma vez. DMs traduzidas on-device (NLLB-200 wasm) — server zero-knowledge.

Conversar com qualquer comunidade global no seu idioma — e ser entendido no idioma deles.

CLD3 detectDeepL públicoon-device E2E
leia mais
Recurso 09

Conversas privadas 1↔N

Threads E2E isoladas dentro de uma sala maior. Outros membros não veem que existem. Reusa group-relay com chave derivada por sub-thread. Max 12 pessoas.

Criar uma panela secreta dentro de uma comunidade — invisível para os outros membros.

group-relayalias-awareinvisível
leia mais
Recurso 10

P2P Escrow · smart contract

Smart contract escrow não-custodial para comércio P2P. O contrato on-chain governa as regras — ninguém controla os fundos. Liberação só quando ambas as partes depositam e confirmam.

Vender diretamente para outro peer, sem corretora, sem confiança — smart contract governa.

escrow on-chainsmart contractP2P
leia mais
Recurso 11

Sugerir mercados locais

Wizard 3 passos (geo · horizonte · pergunta YES/NO). Sugestão postada nas salas relevantes. Comunidade vota por 24h. Threshold 50 → admin abre oficial.

Abrir um mercado preditivo sobre algo que só sua cidade ou bairro liga — sem precisar pedir pra ninguém.

wizard 3-stepsvoto comunidadethreshold 50
leia mais
Recurso 12

Moderação transparente

Moderação ≠ leitura. Admin age sobre peerIds reportados (rate-limit, suspensão) — nunca lê conteúdo. RBAC 4 níveis (owner/admin/moderator/auditor) · audit log com chain hash + assinatura Dilithium · warrant canary público.

Saber que ninguém — nem a Mytho — pode ler suas mensagens. E que cada ação de moderação é auditável externamente.

RBAC 4 níveisaudit chaincanary
leia mais
R01

Identidades múltiplas

N personas Dilithium independentes na mesma instalação. Cada uma com chave própria, peerId próprio, sem correlação no servidor — para o relay são pessoas diferentes.

  • Para quê serve: separar trabalho/família/anônimo sem precisar de N contas, N telefones, N apps.
  • Como funciona: IndexedDB cifrado com Argon2id, switch reconecta WebSocket com nova chave, backup BIP-39 24 palavras por persona.
  • Limite: 5 personas simultâneas, PoW (~5s CPU) na criação, throttle 1/h e 3/dia por IP.
Dilithium ML-DSA-65Argon2idBIP-39 backup
R02

Auto-destruct granular por mensagem

Cinco políticas de destruição que você escolhe antes de enviar cada mensagem. Não é "modo efêmero" do chat inteiro — é controle por unidade.

  • Policies: view-once (destrói no render) · view-timer (N segundos após abrir) · received-timer (timer no recipient) · fixed-ttl (data exata) · revogável (você apaga depois).
  • Screenshot detect: iOS UIApplicationUserDidTakeScreenshotNotification + Android ContentObserver. Não bloqueia (impossível no iOS), mas notifica o autor.
  • Limite: hardcap servidor 48h (DM) / 72h (grupo). Cliente decide tudo dentro desse intervalo.
5 policieszion:revoke-messagescreenshot alert
R03

Salas efêmeras descobríveis por código/QR/BLE

Sala criada com código de 6 caracteres (base32 sem ambíguos). Quem entrar em N minutos participa. Sala se autodestrói no fim do evento.

  • Discovery: código texto · QR compartilhável · broadcast Bluetooth BLE · mDNS local em wifi.
  • Como funciona: chave roomKey gerada no cliente, server só armazena hash. Mensagens dentro respeitam padding bins e somem com a sala.
  • Limite: joinWindow máx 30min · lifetime máx 480min (8h) · membros máx 100.
base32 sem ambíguosHMAC join-proofBLE/mDNS local
R04

Voice rooms anônimos · WebRTC mesh

Salas de áudio em tempo real, anônimas, com gravação impossível no servidor — porque servidor não passa pelo áudio.

  • Como funciona: WebRTC mesh peer-to-peer (cada participante conecta com todos). Server faz APENAS troca de SDP/ICE cifrada.
  • Limite técnico: 12 participantes simultâneos (mesh fica instável acima). UI mostra "ANÔNIMO #012" — nada de nome real.
  • Para quê: grupos de apoio (AA/NA), suporte psicológico peer-to-peer, discussão política em região de censura, brainstorm sem ata.
WebRTC meshSTUN público Cloudflareáudio nunca toca server
R05

Modo deniable · plausible deniability cryptográfica

Mensagens onde o recipient sabe que veio de você, mas não pode provar a terceiros. Inspirado em OTR (Off-the-Record).

  • Como funciona: sender NÃO assina com Dilithium. Usa MAC simétrico com chave compartilhada da sessão. Ambas as partes podem produzir o MAC — então o MAC não vincula.
  • Para quê: whistleblowing (jornalista publica conteúdo sem comprovar fonte), negociação salarial, conversas em região hostil.
  • Limitação honesta: não impede screenshot. Não impede gravação de tela. Só garante que o MAC não vincula sender — defesa legal afirmativa, não invisibilidade.
MAC simétricoOTR v4 / MLSDouble Ratchet derived
R06

Stories efêmeras em sala/comunidade

Stories estilo Instagram, mas só membros da sala/esfera vêem. Anônimas opcionais. Sem feed público, sem followers, sem algoritmo.

  • Diferencial: Instagram = público, performance, algoritmo, anúncios. Mytho stories = privado, contextual, expira. "Stories como conversa, não como vitrine."
  • Anônimo: autor pode optar — círculo cinza neutro, autor não revelado, vê contador "X pessoas viram" mas não quem.
  • Limite: max 5MB image / 30MB vídeo curto · TTL 1min–24h · max 20 stories ativas por peer.
por-sala E2Esem reactionsanon opcional
R07

Lightning · pagamentos P2P não-custodiais

Mytho NÃO custodia. É um passthrough UX sobre a wallet Lightning do usuário (BlueWallet, Phoenix, Wallet of Satoshi). Server nunca toca preimage, saldo ou chave.

  • Lightning: sender pede invoice da própria wallet (LNURL ou deep link), cifra E2E, envia. Recipient cola no app de wallet via deep link lightning:lnbc....
  • On-chain (futuro): possibilidade de integrar pagamentos on-chain genéricos via smart contract, mantendo o mesmo princípio não-custodial.
  • Princípio: nenhum dado financeiro passa pelo chat. O servidor é um relay de bytes opacos — nunca vê valores, contas ou comprovantes.
BOLT-11passthroughnão-custodial
R08

Auto-idioma + tradução bidirecional

Cada sala detecta seu idioma dominante. Você decide uma única vez se quer tradução de leitura, de escrita, ou ambas — preferência salva por sala.

  • Leitura: mensagem chega em EN, você vê original + tradução PT abaixo, dimmed.
  • Escrita: você digita em PT, sistema entrega no idioma da sala. Composer mostra preview ao vivo.
  • DMs e threads privadas: tradução acontece on-device (NLLB-200 distill via WASM, ~500MB cache local) — server permanece zero-knowledge.
CLD3 detectDeepL publicNLLB-200 wasm
R09

Conversas privadas 1↔N dentro de salas

Threads E2E completamente isoladas do chat público de uma sala. Outros membros não veem nem que a thread existe.

  • Como funciona: reusa group-relay do protocolo. Cliente gera threadKey aleatória, distribui via prekeys X3DH-PQ dos membros. Server vê só rota de bytes opacos.
  • Alias-aware: se você entrou na sala com alias, na thread você aparece com alias também — preserva o contrato da sala mãe.
  • Limite: max 12 membros por thread · forward secrecy · histórico 72h Redis · sem tradução server-side (on-device only).
group-relayDouble Ratchetinvisível
R10

P2P Escrow · smart contract on-chain

Comércio direto entre peers com escrow governado por smart contract (.sol). Nenhuma parte — nem o operador — controla os fundos. O contrato só libera quando ambas as partes cumprem as condições acordadas.

  • Fluxo: seller posta oferta → buyer aceita → DM privada com escrow abre → buyer deposita no contrato → seller deposita/confirma → contrato libera automaticamente para ambos (swap atômico on-chain).
  • Segurança: contrato .sol imutável e auditável. Nenhuma das partes pode retirar unilateralmente. Disputas resolvidas por timeout (refund automático) ou arbitragem on-chain se configurada.
  • Taxa: definida no contrato (transparente e imutável). Sem fees ocultos.
smart contract .solescrow on-chainP2P trustless
R11

Sugerir mercados locais (wizard + comunidade)

Usuário sugere mercado preditivo via wizard 3-steps. Comunidade vota por 24h. Threshold passado → admin abre oficial.

  • Wizard: (1) geografia — país, cidade auto-detectada, bairro opcional. (2) horizonte — 30/90/180 dias + trending pills via AI Factory. (3) pergunta YES/NO + fonte oficial + data de resolução.
  • Voto: ▲ apoiar · ▼ rejeitar · ◇ discutir. Threshold = 50 votos a favor em 24h. PoW 5s anti-spam na submissão.
  • Aprovação: admin pode editar pergunta antes de aprovar. Aprovado → markets-service cria oficial, notifica autor + apoiadores.
wizard 3-stepsAI Factory trendingcommunity vote
R12

Moderação transparente · audit chain assinada

Administração centralizada, mas operação verificável externamente. RBAC com 4 níveis. Toda ação assinada com Dilithium em chain hash.

  • RBAC: owner · admin · moderator · auditor. Owner controla kill-switch global; auditor é read-only e pode exportar audit log.
  • Audit chain: cada entry tem prev_hash + this_hash + Dilithium sig do admin. Tampering quebra a cadeia. Verificável por qualquer terceiro com a pubkey do admin.
  • Zero-knowledge: server não decifra DMs/threads/voice/stories. Moderação via reports externos contra peerIds + hash-matching opcional client-side (CSAM PhotoDNA).
RBAC 4 níveisaudit chain Dilithiumwarrant canary
DO TEXTO À ENTREGA

Sua mensagem passa por 8 camadas.
O servidor não atravessa nenhuma.

Cada passo acontece no seu dispositivo, antes de qualquer byte tocar a rede.

01

Você digita

Teclado isolado do app impede captura por apps de acessibilidade ou teclados de terceiros.

texto nunca toca outro processo
02

Chave única por mensagem

Double Ratchet deriva uma chave nova a cada envio. Comprometer uma chave não revela passado nem futuro.

forward secrecy
03

Cifra ChaCha20-Poly1305 autenticada

Qualquer adulteração é rejeitada antes da decifragem. AEAD garante integridade junto com confidencialidade.

AEAD · adulteração detectada
04

Handshake pós-quântico ML-KEM-768

Primeiro contato usa o algoritmo padronizado pelo NIST. Tráfego capturado hoje não decifrável amanhã, nem com computador quântico.

FIPS 203 · harvest-now-decrypt-later imune
05

Sealed sender

O remetente é cifrado dentro do envelope. O relay só sabe pra quem entregar — não sabe de quem veio.

relay não vê quem fala com quem
06

Padding bins + fragmentos opacos

Tamanho real ofuscado em buckets fixos. Redis guarda blobs que não sabe abrir. TTL hardcoded 48h/72h. Confirmou → some.

sem disco persistente · padding ativo
07

Direto quando possível

Se ambos peers online, WebSocket entrega sem armazenar. Voice rooms vão P2P puro via WebRTC mesh.

P2P · pure RAM in-flight
08

Ao fechar, RAM zerada

Chaves de sessão e mensagens existem só em memória. Encerrar o app sobrescreve a região de memória.

sem rastro local
PROPRIEDADES DA ARQUITETURA

Não são promessas.
São propriedades do código.

Se a chave não está no servidor, o servidor não pode entregá-la — mesmo que queira.

Nem nós podemos ler

Chaves de sessão existem só nos dispositivos. Backdoor destruiria o protocolo — não conseguiríamos criar um sem revelar.

propriedade matemática

Sem identidade vinculada

peerId = hash da chave Dilithium. Sem número, sem email, sem documento. Se o servidor sumir, sua identidade persiste no seu dispositivo.

identidade autônoma

TTL automático

48h em 1:1, 72h em grupos, mínimo configurável de 5 minutos. Confirmou recebimento → some na hora.

48h · 72h · 5min mínimo

Pós-quântico por padrão

ML-KEM-768 + ML-DSA-65 desde o primeiro byte, padronizados pelo NIST em 2024. Sem configuração, sem opt-in.

FIPS 203 · FIPS 204

Sealed sender

O relay roteia pelo destinatário. O remetente vai cifrado dentro do envelope, decifrado só pelo destinatário.

relay não conhece o grafo

Sem backup em nuvem

Não existe iCloud, Drive, ou Telegram-style server history. Trocar de dispositivo é re-handshake, não restore.

sem backup · sem regresso
CASOS DE USO REAIS

O que você pode fazer aqui
que não pode em outro lugar.

Cada caso aproveita um recurso específico. Cada um seria impossível arquiteturalmente no WhatsApp ou Telegram.

recursos 01 · 09

"Tenho uma persona profissional, uma pessoal, e uma para o que ninguém precisa saber. Nenhuma sabe das outras."

jornalista · whistleblower
recurso 03

"Criei uma sala para um evento da comunidade. Acabou o evento, sumiu tudo. Privacidade local, efêmera."

comunidade local
recurso 04

"Grupo de apoio AA semanal. Anônimos, ao vivo, áudio P2P. Nem o servidor escuta."

grupos de apoio
recurso 02 · 05

"Conversas profissionais sensíveis. Modo deniable + auto-destruct. Privacidade onde eu preciso."

conversas sensíveis
recurso 07

"Mandei sats pro garçom direto no chat. Lightning, sem intermediário. Sem dados bancários expostos."

pagamentos P2P
recurso 10

"Vendi minha posição direto pra outro trader. Escrow on-chain, sem corretora, sem confiança — smart contract governa."

comércio P2P
recurso 11

"Abri um mercado sobre se vai abrir ciclovia no meu bairro. 50 vizinhos votaram, virou oficial."

comunidade local
recurso 08

"Sala global de cripto, 14 dos 18 falam inglês. Escrevo em PT, eles leem em EN. Ninguém percebe."

comunidade internacional
recurso 03 · 06

"Date Tinder. Sala efêmera, expira 3h depois. Posto stories anônimas durante. Sem trocar telefone."

novos vínculos
COMPARATIVO ESMAGADOR

mytho.chat vs.
Signal, WhatsApp, Telegram.

Crédito onde existe — criptografia forte já é padrão de mercado. Mas há doze coisas que os mensageiros tradicionais não fazem. Tudo verificável.

ASPECTO ⬡ mytho.chat Signal WhatsApp Telegram
Criptografia & protocolo
E2E padrão em 1:1 sempre sempre sempre ~só "secretos"
E2E em grupos nunca
Handshake pós-quântico ML-KEM-768 PQXDH 2023 PQXDH 2024
Ratchet contínuo pós-quântico híbrido ~em transição ~em transição
Sealed sender 2018
Identidade & metadados
Sem número de telefone identidade matemática obrigatório obrigatório obrigatório
R01 · Identidades múltiplas por instalação N ilimitado ~workaround
Grafo social no servidor não temos ~mínimo completo amplo
Retenção & auto-destruct
Mensagens expiram do servidor 48h · 72h hardcap ~entrega e apaga ~entrega e apaga indefinido
R02 · TTL por mensagem (não por chat) 5 policies ~só por chat ~só por chat ~só secretos
Backup nuvem operadora não existe não existe ~opcional iCloud servidor próprio
Espaços efêmeros & presença
R03 · Salas efêmeras código/QR/BLE 8h max
R04 · Voice rooms anônimos (mesh P2P) max 12 · anon ~grupos não anon
R06 · Stories em comunidade privada anon opcional ~status público ~stories público
R09 · Threads privadas 1↔N dentro de sala invisíveis
Conteúdo & defesa legal
R05 · Modo deniable (MAC-only)
Screenshot detection cliente notifica autor ~só view-once ~só view-once ~só secretos
Histórico entregável a autoridades não existe pós-TTL ~criação + último uso via backup nuvem IP+telefone · 2024*
Comércio & pagamentos
R07 · Lightning sem KYC passthrough BOLT-11 ~MobileCoin (morto) ~precisa banco ~TON wallet
R07 · Lightning P2P sem intermediário passthrough BOLT-11
R10 · P2P escrow via smart contract escrow on-chain
Comunidade & idioma
R08 · Auto-tradução por sala (read+write) on-device DM ~só leitura · cloud ~só leitura · cloud
R11 · Sugerir mercados locais (voto) threshold + admin
Transparência & auditoria
R12 · Audit chain Dilithium verificável externo ~transparency report ~Meta report
Código auditável open source (V1.0) open source proprietário ~cliente open
Warrant canary PGP-assinado ~transparency report

NOTAS · FATOS VERIFICÁVEIS

* TelegramEm agosto de 2024, o CEO do Telegram foi preso na França e a empresa mudou sua política de privacidade. Segundo dados públicos: 2.253 usuários a autoridades dos EUA em 2024; 1.386 a autoridades francesas só no Q4 2024; 668 requisições francesas no Q1 2025 (vs 4 no Q1 2024). Chats normais e grupos nunca tiveram E2E real.

** SignalPadrão-ouro em criptografia. Pioneiro em PQXDH (2023) e em sealed sender (2018). Signal escolheu um eixo — pureza de protocolo + universalidade via telefone. mytho.chat explora outro eixo — efemeridade + identidades múltiplas + comércio embutido. São produtos com filosofias diferentes, não competidores diretos.

*** WhatsAppPQXDH desde fev/2024. E2E sólido. Mas: backups iCloud/Drive não-E2E por default, grafo social completo nos servidores, exige telefone, propriedade da Meta. Recursos novos (stories, payments) são públicos ou ligados a banco — não funcionam como aqui.

**** mytho.chat"Não temos" significa literalmente — os dados não existem após TTL. Não é política revogável; é propriedade arquitetural. 12 recursos exclusivos publicados na seção anterior; cada um auditável no código quando publicarmos a V1.0 sob BSL.

PROTOCOLO ABERTO

O protocolo é público.
Verifique você mesmo.

A especificação criptográfica completa do mytho.chat é open source — incluindo o wire-format byte a byte, a máquina de estados do ratchet pós-quântico, a tabela canônica de derivação de chaves e 12 vetores de teste determinísticos. Qualquer criptógrafo pode auditar.

Especificação v1.0

Protocolo completo: ML-KEM-768 (FIPS 203), ML-DSA-65 (FIPS 204), XChaCha20-Poly1305, HKDF-SHA-256 com domain separation canônica, Double Ratchet pós-quântico. Wire-format binário byte-preciso. Conformance com MUST/SHOULD/MAY (RFC 2119).

GitHub → mythochat/protocol

12 KAT Vectors

Known-Answer Test vectors determinísticos cobrindo: derivação de peerId, encoding AAD 38 bytes, padding ISO/IEC 7816-4, nonce AEAD, HMAC de delivery token, ratchet multi-step, AEAD roundtrip, ML-DSA sign/verify e ML-KEM encaps/decaps. Regeneráveis e verificáveis.

vectors/*.json

Internal AI-Assisted Review

Revisão técnica interna assistida por LLM, cobrindo 6 dimensões: correção criptográfica, precisão wire-format, segurança do ratchet, threat model, tooling KAT e consistência. NÃO substitui auditoria externa formal por firma acreditada — esta está planejada (ver SECURITY.md §16). Todos os 12 vetores re-derivados byte a byte.

Security Review →

Licença Apache 2.0

O protocolo é livre para estudo, implementação e auditoria. Não pedimos confiança — publicamos tudo para que você não precise confiar.

LICENSE
"Toda mensagem que você manda hoje
pode existir para sempre.
O passado digital não morre —
ele apenas espera."

Cada mensagem no WhatsApp pode ser entregue à polícia em 2030. Pode ser usada num processo trabalhista em 2035. Pode vazar em hack em 2040. Pode treinar IA em 2045. O servidor central com as chaves é um ponto de pressão — e pontos de pressão cedem.

Em agosto de 2024, o fundador do Telegram foi preso. Nos seis meses seguintes, a plataforma — que vendia privacidade — entregou identificadores de mais de três mil usuários a autoridades. Não por maldade. Por estrutura.

Mytho devolve o direito ao efêmero. Identidades que você pode descartar. Salas que somem quando o evento acaba. Mensagens que vivem 30 segundos, 30 minutos, ou 30 horas — não 30 anos. Comércio direto entre pares. Stories que só sua tribo vê. Voice anônima onde o servidor nem escuta.

Construímos doze recursos que nenhum mensageiro tradicional faz — não porque não saibam, mas porque a arquitetura de todos eles exige número de telefone e armazena grafo social. Cada recurso desta página aproveita uma propriedade que só existe num sistema sem identidade vinculada e sem servidor central.

Não te diremos quem somos. Te diremos o que construímos. E te daremos o código pra você verificar.

ORÁCULO
The Mytho Project · mytho.chat · 2026
TRANSPARÊNCIA OPERACIONAL

Não pedimos confiança.
Damos verificação.

Auditoria pública. Sinais verificáveis. Política clara sobre o que entregamos quando obrigados — e o que literalmente não existe para entregar.

Código aberto

Protocolo criptográfico publicado sob Apache 2.0. Especificação v1.0 com 12 KAT vectors determinísticos, revisão interna assistida por LLM (auditoria externa independente planejada), e CI com leak-gate permanente.

GitHub → mythochat/protocol

Warrant Canary

Declaração PGP-assinada, atualizada periodicamente, afirmando que não recebemos ordem de backdoor, entrega de chaves ou gag order. Página parar de atualizar = sinal.

Ver canary

AUP firme

Proibido: CSAM, terrorismo, tráfico humano, fraude financeira identificada, malware C2. Moderação via reports externos contra peerIds + hash-match opcional client-side. Nunca lemos conteúdo.

Ler AUP

O que entregamos a autoridades

Tudo que temos: hash do peerId, chaves públicas, IPs de conexão ativa (rotacionados em 24h), heartbeats. Não temos conteúdo, identidades reais, histórico após TTL ou grafo social.

Privacy Policy