Para os Entusiastas

A coisa mais divertida em construir o Hashiverse é que não pôde ser construído como software tradicional. A sua independência absoluta de qualquer governo soberano ou empresa significou que não podíamos depender de fornecedores de cloud centralizados nem de servidores ou bases de dados. Caramba — nem sequer de DNS e dos certificados web padrão!

Qualquer pessoa pode modificar o código-fonte dos servidores ou dos clientes e participar no protocolo Hashiverse, por isso até o próprio protocolo tem de ser imune a maus atores.

Aqui ficam alguns dos detalhes de implementação de que mais gostamos no Hashiverse. Cada um aponta para o código-fonte, para que possas seguir a ideia diretamente até ao código.

Os gostos e os não-gostos contam-se a si próprios — sem servidores centrais

Contar numa rede distribuída é uma porcaria. Recorremos à estatística para fazer contagem distribuída nos nossos mecanismos de feedback. Cada sinal de feedback transporta a sua própria PoW, e cada bit adicional de PoW duplica o número estimado de cliques de feedback. Os clientes fundem o feedback de vários servidores escolhendo o sinal mais forte por publicação, e depois recuperam os pares mais fracos. A rede converge sem nenhum coordenador. Não nos importam contagens exatas — em números suficientemente grandes estamos no terreno estatístico certo, e é diabolicamente difícil de manipular.

Origem: encoded_post_feedback.rs, post_bundle_feedback_healing.rs

Uma publicação viral recruta a rede inteira como CDN

Quando um servidor vê pedidos de obtenção suficientes para o mesmo conteúdo, começa a colocá-lo em cache. O cliente que está a ir buscar carrega os dados para povoar essa cache. Para uma publicação viral, todos os servidores ao longo do caminho de pesquisa de cada cliente tornam-se nós de cache. Quanto mais popular o conteúdo, mais servidores o colocam em cache — a rede escala-se a si própria.

Origem: post_bundle_caching.rs

Os hashtags em tendência emergem do nada

Sem contadores centrais. Como "em tendência" significa que muitos utilizadores estão a publicar, a vista local de qualquer servidor aleatório já aproxima a verdade global. Cada servidor segue os autores únicos por hashtag usando um pequeno contador probabilístico. As contagens são dirigidas ao servidor do publicador — por isso só podes inflacionar a contagem do teu próprio servidor, e mesmo assim o mesmo autor a publicar 1000 vezes conta como um. Isto significa que fazer um hashtag entrar em tendência é quase impossível de manipular.

Origem: dispatch.rs, hyper_log_log.rs

O conteúdo esquecido morre por abandono, não por velhice

Sem TTL. Sem temporizador de expiração. Quando o armazenamento de um servidor enche, ele evict o conteúdo menos recentemente acedido. O conteúdo popular é tocado constantemente e sobrevive indefinidamente. O conteúdo que ninguém lê desaparece silenciosamente, por seleção natural baseada no padrão de acesso.

Origem: environment.rs

A auto-recuperação só acontece quando alguém se importa

Quando um cliente vai buscar conteúdo a vários servidores e descobre que um tem publicações em falta que outro tem, repara a lacuna — mas só porque estava a ler. O conteúdo que ninguém lê nunca é recuperado. O conteúdo sob consumo ativo é recuperado sempre que um cliente o vai buscar. A leitura é o fator de replicação.

Origem: post_bundle_healing.rs

O bootstrap não confia em ninguém — nem mesmo no DNS

Três domínios de bootstrap em três regiões, cada um resolvido através de três fornecedores independentes de DNS-over-HTTPS com validação DNSSEC. Os resultados são desduplicados e baralhados. Mesmo assim, cada par recebido tem de passar a verificação criptográfica completa antes de o cliente confiar nele. Um fornecedor de DNS comprometido não consegue injetar pares falsos porque não consegue forjar os milhares de milhões de hashes que cada identidade de servidor exige.

Origem: dnssec_bootstrap_provider.rs, peer_tracker.rs

Certificados TLS para endereços IP — sem necessidade de DNS

Os browsers recusam HTTPS a um IP nu, a menos que o certificado cubra esse IP. As CAs tradicionais só emitiam certificados para nomes de domínio — o que tornaria cada servidor dependente do DNS. No final de 2025, a Let's Encrypt começou a emitir certificados de IP. Estávamos à espera deste momento. Cada servidor auto-provisiona e renova o seu próprio certificado de IP em segundo plano. Os clientes de browser podem percorrer a DHT diretamente por IP sobre HTTPS de confiança.

Origem: https_transport_cert_refresher.rs

O teu filtro de spam corre sobre termodinâmica, não sobre bases de dados

Cada envelope RPC transporta uma solução de proof-of-work. Os servidores rejeitam qualquer coisa abaixo do limiar antes mesmo de fazer parsing do payload. Sem CAPTCHA, sem base de dados de rate-limit, sem verificação de conta. O custo é invisível para um utilizador legítimo, mas leva o spammer à falência. E esta PoW serve adicionalmente para fortalecer a reputação dos servidores e ajudar a afastar maus atores.

Origem: rpc_request.rs

Os endpoints sensíveis custam exponencialmente mais para chamar (e fazer spam)

Um RPC de rotina custa cerca de 65 mil hashes. Falar com um servidor desconhecido custa 4× mais. Publicar custa 16× o baseline. O feedback custa 32×. Criar uma identidade de servidor custa milhares de milhões de hashes (horas de trabalho). Cada camada está dimensionada com precisão ao seu potencial de abuso.

Origem: config.rs

O raio da cache expande como uma onda de choque

Os clientes seguem até onde, a partir dos servidores de origem, os dados em cache se propagaram. Cada hit de cache empurra o raio mais para fora. As pesquisas futuras começam para lá do raio, batendo em servidores frescos em vez de martelarem a origem. O conteúdo popular irradia para fora, o que significa que outros clientes encontram dados em cache cedo no seu passeio. O conteúdo obscuro permanece local e sem cache. Sem configuração, sem afinação — o protocolo adapta-se por simples observação.

Origem: cache_radius_tracker.rs

Vários níveis de granularidade de baldes domam a lei de potência

Ano → mês → semana → dia → 6 horas → 1 hora → 15 min → 5 min → 1 min. Um utilizador que publique uma vez por mês custa um único fetch a um balde grosseiro. Um utilizador que publique 100 vezes por dia desce até baldes ao minuto, obtidos em paralelo. Mesmo protocolo, mesmo código, perfis de carga radicalmente diferentes tratados de forma graciosa.

Origem: buckets.rs

Os baldes cheios dividem-se — não partem

Quando um balde de cronologia enche, sela-se. Os clientes veem a flag e descem para os filhos de granularidade mais fina. Um hashtag em tendência cascata de baldes horários para 15 minutos para 1 minuto à medida que o volume dispara, espalhando automaticamente a carga por servidores diferentes.

Origem: dispatch.rs, buckets.rs

Um único código-base, todas as plataformas — a sério

hashiverse-lib compila para Rust nativo (servidor) e WebAssembly (browser). A lógica do protocolo, a criptografia e a API do cliente são o mesmo código a correr em ambos os ambientes. O browser carrega-o num Web Worker para que a thread principal nunca bloqueie. Quando testas o servidor, estás a testar o mesmo código que o browser corre.

Origem: hashiverse-lib/, hashiverse-client-wasm/

Testes de integração com 100 servidores que terminam em segundos

O transporte em memória substitui o HTTP — latência de rede zero, sem portas, sem limpeza. O tempo corre a 300× a velocidade real, comprimindo 30 minutos de descoberta de pares em 6 segundos de relógio de parede. 100 servidores, 3 clientes, bootstrap completo, submissão de publicações, auto-recuperação e verificação — um processo, em menos de 30 segundos.

Origem: client_meets_servers.rs

Adeus ASICs! A cadeia de PoW é auto-referencial

Cinco rondas de hashing encadeado em 17 algoritmos de hashing de última geração. O algoritmo de cada ronda e a contagem de repetições são derivados do output da ronda anterior. A sequência depende dos dados — um ASIC desenhado para ser rápido num algoritmo não ganha nada se a cadeia passar por outros cinco. Esperamos pelo dia em que o Hashiverse terá tanto sucesso que ASICs personalizados se tornem suficientemente económicos para o tentar derrubar.

Origem: pow.rs

Identidade à prova de quântico, comprometida hoje

Cada identidade incorpora compromissos com dois algoritmos de chave pós-quântica (Falcon e Dilithium) a par da chave clássica Ed25519. O caminho de atualização está cozido em cada identidade da rede — antes de existirem computadores quânticos. Duas suposições independentes baseadas em lattices; ambas têm de quebrar em simultâneo. Em resumo, a tua identidade Hashiverse não vai partir se os computadores quânticos se tornarem mainstream.

Origem: keys_post_quantum.rs

Sem palavras-passe, sem e-mail, sem problema

Sem servidores centrais significa sem base de dados de palavras-passe e sem e-mail para te enviar spam. Geres as tuas próprias chaves — e damos-te três formas. Modo convidado: zero configuração, só de leitura, basta começares a navegar. Frase-chave: introduz uma passphrase, a mesma frase dá a mesma identidade em qualquer dispositivo. Passkey: a tua impressão digital ou Face ID torna-se a tua chave através do secure enclave do dispositivo — suportada por hardware, sincronizada entre dispositivos, zero palavras-passe para memorizar.

Origem: key_locker.rs, login/

Um único ciphertext, 32 chaves

As publicações são cifradas em repouso e em trânsito. Sem espreitadelas nem pós-processamento por servidores manhosos. Uma única publicação cifrada pode ser decifrada com até 32 passphrases diferentes — uma por contexto em que aparece. O cabeçalho é auto-descritivo, por isso qualquer decifragem futura reconstrói a configuração exata de cifragem só a partir do ciphertext.

Origem: encryption.rs

Cinco camadas de defesa contra DDoS antes de chegares ao código da aplicação

Camada 1: PoW em cada envelope RPC. Camada 2: pontuação por IP com decaimento temporal. Camada 3: limite de ligações por IP. Camada 4: blacklist de IPs ao nível do kernel quando a pontuação ultrapassa o limiar. Camada 5: timeouts de transporte para o handshake TLS, leitura de cabeçalhos e leitura do corpo (defesa contra Slow Loris).

Origem: ipset_ddos.rs, config.rs

Corre num VPS de 5 $ — por design, não por acaso

Armazenamento LSM-tree comprimido em disco. Caches em memória limitadas. Escritas concorrentes com lock-striping. Contadores probabilísticos para tendências (64 bytes por hashtag). E a DHT significa que cada servidor só guarda dados perto do seu próprio ID — não a rede inteira.

Origem: environment/, config.rs

Cada costura do sistema é uma trait substituível

Transporte (canais em memória vs HTTP vs WASM fetch). Tempo (relógio real vs aceleração 300×). Armazenamento (IndexedDB vs em memória). Proteção contra DDoS (ipset do kernel vs pontuação em memória). Gestão de chaves (enclave Web Crypto vs stubs de teste). Troca qualquer uma sem tocar na lógica do protocolo. Os testes usam as baratas; a produção usa as reais; mesmo caminho de código.

Origem: transport/, time_provider/, environment/

PoW no browser distribuída por Web Workers isolados

O cliente WASM aproveita todos os teus núcleos distribuindo a proof-of-work por Web Workers. Cada job concorrente de PoW é isolado para que não interfiram. Os resultados fazem a ponte de Promises do JavaScript para Futures do Rust. A thread principal do browser nunca toca num hash e nunca abranda.

Origem: wasm_parallel_pow_generator.rs

A auto-recuperação desperdiça zero largura de banda

O cliente envia um cabeçalho a descrever o que tem. O servidor responde apenas com os IDs que lhe faltam. O cliente envia exatamente esses bytes. Se o servidor já tiver tudo, é uma única ida-e-volta de cabeçalhos.

Origem: dispatch.rs

Dois algoritmos de compressão, um único byte de versão

LZ4 para pacotes RPC (velocidade). Brotli na qualidade máxima para publicações guardadas (tamanho). Um único byte de versão à cabeça permite a evolução do algoritmo sem partir nenhum dado existente. Abaixo de um tamanho mínimo, a compressão é simplesmente saltada — o overhead excederia as poupanças.

Origem: compression.rs

O recursive bucket visitor nunca recorre

O caminhante de cronologia usa frames de stack explícitos em vez de recursão de funções. Um callback em cada nível decide se desce mais fundo, salta ou para. Cronologias esparsas saltam totalmente os níveis aninhados. Cronologias densas só descem onde existe conteúdo.

Origem: recursive_bucket_visitor.rs