Tesseras

Fase 2: Memórias Sobrevivem

2026-02-14

Uma tessera não está mais presa a uma única máquina. A Fase 2 entrega a camada de replicação: os dados são divididos em fragmentos com codificação de apagamento, distribuídos entre múltiplos pares e reparados automaticamente quando nós ficam offline. Um livro-razão de reciprocidade bilateral garante troca justa de armazenamento — sem blockchain, sem tokens.

O que foi construído

tesseras-core (atualizado) — Novos tipos de domínio de replicação: FragmentPlan (seleciona a camada de fragmentação baseada no tamanho da tessera), FragmentId (hash da tessera + índice + contagem de shards + checksum), FragmentEnvelope (fragmento com seus metadados para transporte na rede), FragmentationTier (Small/Medium/Large), Attestation (prova de que um nó possui um fragmento em um dado momento) e ReplicateAck (confirmação de recebimento de fragmento). Três novas traits de porta definem os limites hexagonais: DhtPort (encontrar pares, replicar fragmentos, solicitar atestações, ping), FragmentStore (armazenar/ler/deletar/listar/verificar fragmentos) e ReciprocityLedger (registrar trocas de armazenamento, consultar saldos, encontrar melhores pares). O tamanho máximo de uma tessera é 1 GB.

tesseras-crypto (atualizado) — O ReedSolomonCoder existente agora alimenta a codificação de fragmentos. Os dados são divididos em shards, shards de paridade são computados, e qualquer combinação de shards de dados pode reconstruir o original — desde que o número de shards ausentes não exceda a contagem de paridade.

tesseras-storage (atualizado) — Dois novos adaptadores:

• FsFragmentStore — armazena dados de fragmentos como arquivos em disco ({raiz}/{hash_tessera}/{indice:03}.shard) com um índice de metadados SQLite rastreando hash da tessera, índice do shard, contagem de shards, checksum e tamanho em bytes. A verificação recalcula o hash BLAKE3 e compara com o checksum armazenado.
• SqliteReciprocityLedger — contabilidade bilateral de armazenamento em SQLite. Cada par tem uma linha rastreando bytes armazenados para eles e bytes que eles armazenam para nós. A coluna balance é uma coluna gerada (bytes_they_store_for_us - bytes_stored_for_them). UPSERT garante incremento atômico dos contadores.

Nova migração (002_replication.sql) adiciona tabelas para fragmentos, planos de fragmentação, detentores, mapeamentos detentor-fragmento e saldos de reciprocidade.

tesseras-dht (atualizado) — Quatro novas variantes de mensagem: Replicate (enviar um envelope de fragmento), ReplicateAck (confirmar recebimento), AttestRequest (pedir a um nó que prove que possui os fragmentos de uma tessera) e AttestResponse (retornar atestação com checksums e timestamp). O engine trata essas mensagens em seu loop de despacho.

tesseras-replication — O novo crate, com cinco módulos:

• Codificação de fragmentos (fragment.rs): encode_tessera() seleciona a camada de fragmentação baseada no tamanho e então chama a codificação Reed-Solomon para as camadas Medium e Large. Três camadas:

  • Small (< 4 MB): replicação do arquivo inteiro para r=7 pares, sem codificação de apagamento
  • Medium (4–256 MB): 16 shards de dados + 8 de paridade, distribuídos entre r=7 pares
  • Large (≥ 256 MB): 48 shards de dados + 24 de paridade, distribuídos entre r=7 pares

• Distribuição (distributor.rs): filtragem de diversidade de sub-rede limita pares por sub-rede /24 IPv4 (ou prefixo /48 IPv6) para evitar falhas correlacionadas. Se todos os seus fragmentos caírem no mesmo rack, uma única queda de energia os elimina.

• Serviço (service.rs): ReplicationService é o orquestrador. replicate_tessera() codifica os dados, encontra os pares mais próximos via DHT, aplica diversidade de sub-rede e distribui fragmentos em round-robin. receive_fragment() valida o checksum BLAKE3, verifica o saldo de reciprocidade (rejeita se o déficit do remetente exceder o limite configurado), armazena o fragmento e atualiza o livro-razão. handle_attestation_request() lista os fragmentos locais e calcula seus checksums como prova de posse.

• Reparo (repair.rs): check_tessera_health() solicita atestações dos detentores conhecidos, recorre ao ping para nós não responsivos, verifica a integridade local dos fragmentos e retorna uma de três ações: Healthy, NeedsReplication { deficit } ou CorruptLocal { fragment_index }. O loop de reparo roda a cada 24 horas (com 2 horas de jitter) via tokio::select! com integração de desligamento.

• Configuração (config.rs): ReplicationConfig com padrões para intervalo de reparo (24h), jitter (2h), transferências simultâneas (4), espaço livre mínimo (1 GB), tolerância de déficit (256 MB) e limite de armazenamento por par (1 GB).

tesd (atualizado) — O daemon agora abre um banco de dados SQLite (db/tesseras.db), executa migrações, cria instâncias de FsFragmentStore, SqliteReciprocityLedger e FsBlobStore, envolve o engine DHT em um DhtPortAdapter, constrói um ReplicationService e lança o loop de reparo como tarefa em segundo plano com desligamento gracioso.

Testes — 193 testes em todo o workspace:

• 15 testes unitários em tesseras-replication (camadas de codificação de fragmentos, validação de checksum, diversidade de sub-rede, verificações de saúde do reparo, fluxos de recebimento/replicação do serviço)
• 3 testes de integração com armazenamento real (ciclo completo codificar→distribuir→receber para tessera média, replicação de arquivo inteiro para tessera pequena, rejeição de fragmento adulterado)
• Testes usam SQLite em memória + diretório temporário para fragmentos com mocks mockall para DHT e BlobStore
• Zero avisos do clippy, formatação limpa

Decisões de arquitetura

• Fragmentação em três camadas: arquivos pequenos não precisam de codificação de apagamento — o overhead não compensa. Arquivos médios e grandes recebem progressivamente mais shards de paridade. Isso evita desperdiçar armazenamento em tesseras pequenas enquanto oferece redundância forte para as grandes.
• Distribuição por push do dono: o dono da tessera codifica os fragmentos e os envia aos pares, em vez dos pares puxarem. Isso simplifica o protocolo (sem fase de negociação) e garante que os fragmentos são distribuídos imediatamente.
• Reciprocidade bilateral sem consenso: cada nó rastreia seu próprio saldo com cada par localmente. Sem livro-razão global, sem token, sem blockchain. Se o par A armazena 500 MB para o par B, o par B deveria armazenar aproximadamente 500 MB para o par A. Free riders perdem redundância gradualmente — seus fragmentos são despriorizados para reparo, mas nunca deletados.
• Diversidade de sub-rede: os fragmentos são espalhados por diferentes sub-redes para sobreviver a falhas correlacionadas. Uma queda de datacenter não deveria eliminar todas as cópias de uma tessera.
• Verificações de saúde por atestação primeiro: o loop de reparo pede aos detentores que provem posse (atestação com checksums) antes de declarar uma tessera degradada. Apenas quando a atestação falha é que ele recorre a um simples ping. Isso detecta corrupção silenciosa de dados, não apenas partida de nós.

O que vem a seguir

• Fase 3: API e Apps — App Flutter mobile/desktop via flutter_rust_bridge, API GraphQL (async-graphql), nó WASM no navegador
• Fase 4: Resiliência e Escala — Assinaturas pós-quânticas ML-DSA, travessia avançada de NAT, Compartilhamento de Segredo de Shamir para herdeiros, empacotamento para Alpine/Arch/Debian/FreeBSD/OpenBSD, CI no SourceHut
• Fase 5: Exploração e Cultura — navegador público de tesseras, curadoria institucional, integração genealógica, exportação para mídia física

Os nós conseguem se encontrar e manter vivas as memórias uns dos outros. Em seguida, damos às pessoas uma forma de segurar suas memórias nas mãos.