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.

- -