Artigo Técnico para Colaboradores

Resumo técnico para colaboradores

Este documento apresenta uma proposta técnica de implementação da Internet 5.0 para revisão por engenheiros, mantenedores de sistemas operacionais, desenvolvedores de navegadores, pesquisadores de segurança, criptógrafos, comunidades Linux, equipes Android/Windows e colaboradores das RFCs.

A Internet 5.0 não é uma tentativa de substituir a pilha TCP/IP. É uma arquitetura incremental, inicialmente em user space no MVP, destinada a integrar sessões seguras, identidade criptográfica, resolução de nomes resistente à censura, múltiplos localizadores, reputação plural, proteção anti-phishing e governança ética sem backdoors.

A proposta está dividida em três blocos técnicos: I5SL, I5NS e I5TRUST.

1. Objetivo de engenharia

O objetivo é criar uma camada de sessão e resolução que permita a uma aplicação solicitar comunicação por identidade e política, em vez de depender exclusivamente de domínio, DNS, IP, rota única ou provedor único.

Aplicação
  ↓
secure_session(identity_or_name, policy, content_type)
  ↓
I5NS Resolver → I5ID + localizadores + reputação
  ↓
I5SL Route/Session Manager
  ↓
TLS/QUIC/HTTPS/IPFS/onion/relay/cache
  ↓
conteúdo verificado por assinatura ou hash

O projeto deve começar como biblioteca, daemon local e extensão de navegador. A integração nativa em sistemas operacionais seria fase posterior, após validação de arquitetura, segurança, UX, desempenho e governança.

2. Blocos técnicos

3. Não objetivos

• não alterar o kernel de sistemas operacionais no MVP;
• não substituir IP, TCP, UDP, TLS, QUIC ou DNS;
• não criar uma blockchain obrigatória;
• não criar autoridade global de nomes;
• não exigir identidade civil ou KYC para leitura de conteúdo público;
• não prometer impossibilidade absoluta de bloqueio;
• não defender descumprimento genérico de decisões judiciais;
• não criar uma rede sem responsabilidade por crimes ou fraudes.

O foco inicial é interoperabilidade, auditabilidade e adoção progressiva.

4. Modelo de ameaça

A arquitetura assume adversários capazes de bloquear DNS, IP, portas, protocolos, lojas de aplicativos ou domínios; adulterar respostas de resolução; classificar tráfego por metadados; degradar rotas; pressionar registradores, provedores, data centers, operadores e plataformas; emitir ordens amplas de bloqueio; explorar nomes parecidos para phishing; capturar listas de reputação; ou forçar downgrade para rotas menos seguras.

A arquitetura não promete proteção contra corte físico de cabos, desligamento nacional de energia, prisão de operadores, controle total de dispositivos, proibição criminal de ferramentas de privacidade ou isolamento completo de redes nacionais.

5. Identidade criptográfica

O I5ID é o identificador derivado de chave pública. Ele não representa identidade civil obrigatória. Representa controle criptográfico.

i5id:ed25519:z6Mkp...

O cliente deve verificar se determinado registro, conteúdo, localizador, revogação ou atualização foi assinado pela chave correspondente.

• o I5ID deve ser autoemitido;
• a leitura de conteúdo público não deve exigir I5ID persistente do leitor;
• publicadores podem usar identidade pública, pseudônima ou organizacional;
• identidades efêmeras devem ser possíveis para sessões sensíveis;
• a reputação deve acompanhar a chave e o histórico, não apenas o nome humano.

6. Registro I5NS

O registro I5NS é o objeto assinado que vincula nome humano, identidade criptográfica e localizadores.

{
  "type": "I5NS-Record",
  "version": "0.1",
  "name": "internet5.i5",
  "canonical_id": "i5id:ed25519:z6MkpExamplePublicKey",
  "created_at": "2026-05-27T00:00:00Z",
  "valid_until": "2027-05-27T00:00:00Z",
  "sequence": 42,
  "locators": [
    {
      "scheme": "https",
      "uri": "https://alexfernando.com/internet5.0/",
      "priority": 10,
      "transport_policy": ["tls13", "ech-preferred"]
    },
    {
      "scheme": "ipfs",
      "uri": "ipfs://bafyExampleHash",
      "priority": 30
    },
    {
      "scheme": "onion",
      "uri": "http://exampleonionaddress.onion/",
      "priority": 40
    }
  ],
  "policies": {
    "downgrade_protection": true,
    "mirroring_allowed": true,
    "reader_identity_required": false,
    "no_backdoor_commitment": true
  },
  "recovery_policy": {
    "type": "m-of-n",
    "required_signatures": 2,
    "recovery_keys": [
      "i5id:ed25519:z6RecoveryKey1",
      "i5id:ed25519:z6RecoveryKey2",
      "i5id:ed25519:z6RecoveryKey3"
    ]
  },
  "signature": {
    "alg": "ed25519",
    "key": "i5id:ed25519:z6MkpExamplePublicKey",
    "value": "base64url-signature"
  }
}

O campo sequence mitiga replay de registros antigos. O campo valid_until força renovação. A política m-of-n reduz risco de perda definitiva por extravio de chave principal.

7. Resolução I5NS

O resolvedor I5NS deve consultar múltiplas fontes e nunca depender de um único servidor soberano: cache local, arquivo .well-known, DNS TXT, DoH, DoT, ODoH, IPFS, logs de transparência, listas de confiança configuráveis, mirrors independentes e registros fixados pelo usuário.

resolve_i5_name(name, context):
    records = collect_from_multiple_sources(name)
    valid = []

    for record in records:
        if not verify_signature(record):
            continue
        if is_expired(record):
            mark(record, "expired")
            continue
        if is_replayed(record):
            mark(record, "replay-risk")
            continue
        valid.append(record)

    reputation = query_i5trust(valid)
    ranked = rank_records(valid, reputation, context)
    return ranked

8. Estabelecimento de sessão I5SL

A API conceitual pode ser:

secure_session(identity_or_name, policy, content_type)

Exemplo de política:

{
  "privacy": "high",
  "require_integrity": true,
  "allow_mirrors": true,
  "allow_onion": true,
  "allow_ipfs": true,
  "fail_closed_on_downgrade": true
}

1. resolver nome via I5NS;
2. validar assinatura e identidade;
3. classificar localizadores;
4. avaliar política de privacidade;
5. tentar rota direta segura;
6. usar ECH/DoH/DoT/ODoH quando disponível;
7. tentar mirror assinado, IPFS, onion, relay ou cache;
8. verificar integridade do conteúdo;
9. retornar sessão ou erro explicável.

9. Ranking de localizadores

O gerenciador de sessão deve classificar localizadores por integridade, privacidade, latência, disponibilidade, risco de censura, preferência do usuário, política do publicador, histórico de sucesso, alertas de reputação, sensibilidade do conteúdo e jurisdição.

if policy.privacy == "high":
    prefer privacy-preserving locators

if policy.require_integrity:
    reject content without valid signature/hash

if censorship_risk == "high":
    avoid single direct route

if locator.reputation == "phishing":
    block or require explicit confirmation

10. Integração com sistemas operacionais

10.1. MVP em user space

• libi5sl — biblioteca de sessão;
• i5nsd — daemon/resolver local;
• i5trustd — verificador de reputação/listas;
• i5ctl — ferramenta de linha de comando;
• i5-record-tool — gerador e validador de registros;
• extensão de navegador demonstrativa.

10.2. Linux

No Linux, o caminho inicial recomendado é um daemon de usuário com socket local, integração opcional com NSS, NetworkManager, navegadores e ferramentas CLI. eBPF, Netfilter ou módulos de kernel devem ser evitados no MVP.

10.3. Windows

No Windows, o caminho inicial é biblioteca em user space e serviço local. Integração posterior poderia explorar Windows Filtering Platform, mas isso não deve ser exigência inicial.

10.4. Android

No Android, o MVP pode começar com SDK por aplicação, serviço local integrado a apps participantes ou protótipo com VpnService. A maturidade desejada seria integração com resolver do sistema, política de rede por app e API nativa de sessão segura.

10.5. Navegadores

Navegadores são o ponto de adoção inicial mais estratégico: resolução .i5, verificação de I5ID, alertas de phishing, detecção de homógrafos, fallback para localizadores e painel de confiança.

11. I5TRUST: anti-phishing e reputação plural

I5TRUST não é lista central. É um modelo de listas plurais, assinadas, auditáveis, contestáveis e opcionais no nível do protocolo.

• Trust List;
• Warning List;
• Fraud List;
• Phishing List;
• Compromised Key List;
• Dispute List;
• Brand Impersonation List;
• High-Risk Identity List.

Um alerta deve conter emissor, alvo, nome afetado, motivo, evidências, severidade, data, expiração, canal de contestação e assinatura. O protocolo não deve apagar globalmente uma identidade.

12. Proteção contra especulação com nomes

• reputação segue a identidade, não apenas a string;
• transferência de nome não transfere confiança automaticamente;
• nome sem uso pode receber baixa reputação;
• prova de controle aumenta confiança;
• histórico público aumenta confiança;
• conflito deve ser exibido, não apagado por autoridade única;
• I5ID é raiz técnica; nome humano é alias.

13. Logs de transparência

Logs de transparência não devem ser registradores soberanos. Eles apenas provam eventos: reivindicação de nome, atualização de localizadores, revogação de mirror, substituição por recuperação m-of-n, disputa de nome ou alerta emitido por lista de reputação.

Clientes devem consultar mais de um log. Nenhum log deve possuir poder de revogação global.

14. Segurança

Ameaças

• comprometimento ou perda de chave;
• replay de registro antigo;
• mirror malicioso;
• relay hostil;
• correlação de tráfego;
• enumeração de identidades;
• negação de serviço contra logs;
• captura de lista de reputação;
• coerção estatal contra operadores;
• ataques Unicode homograph;
• downgrade para conexão comum;
• substituição de conteúdo em cache.

Mitigações

• sequence number;
• validade temporal curta;
• assinatura obrigatória;
• hash de conteúdo;
• recuperação m-of-n;
• listas plurais;
• cache local;
• consulta por múltiplas fontes;
• logs de transparência;
• alertas de homógrafo;
• pinning opcional;
• fail-closed em modo estrito;
• auditoria de código.

15. Privacidade e desempenho

A especificação deve evitar transformar o I5NS em ferramenta de vigilância. O leitor não deve precisar de identidade persistente; consultas devem poder ser privadas; logs não devem registrar IP de consulta; listas de reputação devem permitir download periódico; clientes devem evitar telemetria desnecessária.

O risco principal é latência de resolução. Mitigações incluem cache local, prefetch, download periódico de listas, consulta paralela a múltiplas fontes, ranking por histórico, verificação assíncrona de reputação, modo offline para registros fixados e fallback progressivo.

16. MVP recomendado

17. Test vectors obrigatórios

Para interoperabilidade, o projeto deve publicar vetores de teste para registro válido, assinatura inválida, registro expirado, registro replay, sequence antigo, chave revogada, nome em disputa, localizador malicioso, homógrafo Unicode, phishing warning, trust list válida, trust list expirada, recuperação 2-of-3 válida e recuperação 1-of-3 inválida.

18. Perguntas abertas para colaboradores

1. O formato canônico deve ser JSON, CBOR, COSE, JOSE ou outro?
2. Ed25519 é suficiente para o draft inicial?
3. Qual estratégia pós-quântica deve ser prevista?
4. Como evitar centralização de logs de transparência?
5. Como impedir Sybil attacks em listas de reputação?
6. Como classificar nomes em disputa sem autoridade central?
7. Como equilibrar alerta anti-phishing com risco de censura privada?
8. Como fazer resolução privada sem latência excessiva?
9. Como integrar com browsers sem depender de extensões?
10. Como criar API de sistema operacional sem quebrar compatibilidade?
11. Como definir política de fail-open e fail-closed?
12. Como proteger usuários em países onde ferramentas de privacidade são criminalizadas?
13. Como implementar em Android sem depender permanentemente de VpnService?
14. Como implementar em Windows sem exigir driver kernel no MVP?
15. Como implementar em Linux sem fragmentar entre distribuições?
16. Como impedir que listas de reputação virem censura terceirizada?

19. Critérios de viabilidade

A proposta é tecnicamente viável se não exigir alteração imediata de TCP/IP, mudança inicial de kernel, autoridade central, adoção global simultânea ou substituição de padrões existentes.

Ela é politicamente viável se não for apresentada como ferramenta de impunidade, não prometer impossibilidade absoluta de bloqueio, adotar governança ética clara, separar combate a crimes de censura estrutural e preservar criptografia forte.

Ela é socialmente valiosa se reduzir censura abusiva, dependência de registradores, especulação com nomes, phishing, falsificação de fontes e exposição de leitores.

20. Conclusão técnica

A Internet 5.0 deve ser compreendida como arquitetura de transição. Ela não substitui a internet atual, não promete invulnerabilidade absoluta, não cria rede sem lei, não exige identidade civil global e não depende de registrador único.

camada de sessão segura;
sistema de nomes baseado em chaves;
múltiplos localizadores assinados;
resolução distribuída;
reputação plural;
alertas anti-phishing;
recuperação descentralizada;
proteção contra downgrade;
privacidade de resolução;
responsabilização nas bordas;
ausência de backdoors.

A pergunta correta para revisão técnica é: é possível criar uma camada aberta, incremental e auditável que aumente disponibilidade, privacidade, autenticidade e resistência à censura sem criar um novo ponto central de controle?

A proposta da Internet 5.0 responde: sim, desde que a arquitetura comece descentralizada, preserve criptografia forte, separe identidade civil de identidade criptográfica, use reputação plural, mantenha responsabilização nas bordas e evolua por implementação progressiva.