Empacotando o Tesseras para Debian

2026-02-16T10:00:00+00:00
O Tesseras agora inclui um pacote .deb</code> para Debian e Ubuntu. Este post explica como compilar e instalar o pacote a partir do código-fonte usando cargo-deb</code>.</p>
Pré-requisitos</h2>
Você precisa de uma toolchain Rust funcional e das bibliotecas de sistema
necessárias:</p>
sudo apt install build-essential pkg-config libsqlite3-dev
rustup toolchain install stable
cargo install cargo-deb
</code></pre>
Compilando</h2>
Clone o repositório e execute a recipe just deb</code>:</p>
git clone https://git.sr.ht/~ijanc/tesseras
cd tesseras
just deb
</code></pre>
Essa recipe faz três coisas:</p>

Compila</strong> tesd</code> (o daemon) e tes</code> (o CLI) em modo release com
cargo build --release</code></li>
Gera completions de shell</strong> para bash, zsh e fish a partir do binário tes</code></li>
Empacota</strong> tudo em um arquivo .deb</code> com
cargo deb -p tesseras-daemon --no-build</code></li>
</ol>
O resultado é um arquivo .deb</code> em target/debian/</code>.</p>
Instalando</h2>
sudo dpkg -i target/debian/tesseras-daemon_*.deb
</code></pre>
Se houver dependências faltando, corrija com:</p>
sudo apt install -f
</code></pre>
Configuração pós-instalação</h2>
O script postinst</code> cria automaticamente um usuário de sistema tesseras</code> e o
diretório de dados /var/lib/tesseras</code>. Para usar o CLI sem sudo, adicione seu
usuário ao grupo:</p>
sudo usermod -aG tesseras $USER
</code></pre>
Faça logout e login novamente, depois inicie o daemon:</p>
sudo systemctl enable --now tesd
</code></pre>
O que o pacote inclui</h2>
Caminho</th> Descrição</th></tr></thead>

/usr/bin/tesd</code></td> Daemon do nó completo</td></tr>
/usr/bin/tes</code></td> Cliente CLI</td></tr>
/etc/tesseras/config.toml</code></td> Configuração padrão (marcado como conffile)</td></tr>
/lib/systemd/system/tesd.service</code></td> Unit systemd com hardening de segurança</td></tr>
Completions de shell</td> bash, zsh e fish</td></tr>
</tbody></table>
Como o cargo-deb funciona</h2>
Os metadados de empacotamento ficam em crates/tesseras-daemon/Cargo.toml</code> na
seção [package.metadata.deb]</code>. Essa seção define:</p>

depends</strong> — dependências em tempo de execução: libc6</code> e libsqlite3-0</code></li>
assets</strong> — arquivos incluídos no pacote (binários, config, unit systemd,
completions de shell)</li>
conf-files</strong> — arquivos tratados como configuração (preservados na
atualização)</li>
maintainer-scripts</strong> — scripts postinst</code> e postrm</code> em
packaging/debian/scripts/</code></li>
systemd-units</strong> — integração automática com systemd</li>
</ul>
O script postinst</code> cria o usuário de sistema tesseras</code> e o diretório de dados
na instalação. O script postrm</code> remove o usuário, grupo e diretório de dados
apenas no purge</code> (não na remoção simples).</p>
Hardening do systemd</h2>
A unit tesd.service</code> inclui diretivas de hardening de segurança:</p>
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/tesseras
PrivateTmp=true
PrivateDevices=true
ProtectKernelTunables=true
ProtectControlGroups=true
RestrictSUIDSGID=true
MemoryDenyWriteExecute=true
</code></pre>
O daemon roda como o usuário não-privilegiado tesseras</code> e só pode escrever em
/var/lib/tesseras</code>.</p>
Deploy para um servidor remoto</h2>
O justfile inclui uma recipe deploy</code> para enviar o .deb</code> a um host remoto:</p>
just deploy bootstrap1.tesseras.net
</code></pre>
Isso compila o .deb</code>, copia via scp</code>, instala com dpkg -i</code> e reinicia o
serviço tesd</code>.</p>
Atualizando</h2>
Depois de baixar novas mudanças, basta rodar just deb</code> novamente e reinstalar:</p>
git pull
just deb
sudo dpkg -i target/debian/tesseras-daemon_*.deb
</code></pre>


Empacotando o Tesseras para Arch Linux
2026-02-16T09:00:00+00:00
O Tesseras agora inclui um PKGBUILD para Arch Linux. Este post explica como
compilar e instalar o pacote a partir do código-fonte.</p>
Pré-requisitos</h2>
Você precisa de uma toolchain Rust funcional e do grupo base-devel:</p>
sudo pacman -S --needed base-devel sqlite
rustup toolchain install stable
</code></pre>
Compilando</h2>
Clone o repositório e execute a recipe just arch</code>:</p>
git clone https://git.sr.ht/~ijanc/tesseras
cd tesseras
just arch
</code></pre>
Isso executa makepkg -sf</code> dentro de packaging/archlinux/</code>, que:</p>

prepare</strong> — baixa as dependências Cargo com cargo fetch --locked</code></li>
build</strong> — compila tesd</code> e tes</code> (o CLI) em modo release</li>
package</strong> — instala binários, serviço systemd, configs sysusers/tmpfiles,
completions de shell (bash, zsh, fish) e um arquivo de configuração padrão</li>
</ol>
O resultado é um arquivo .pkg.tar.zst</code> em packaging/archlinux/</code>.</p>
Instalando</h2>
sudo pacman -U packaging/archlinux/tesseras-*.pkg.tar.zst
</code></pre>
Configuração pós-instalação</h2>
O pacote cria automaticamente um usuário e grupo de sistema tesseras</code> via
systemd-sysusers. Para usar o CLI sem sudo, adicione seu usuário ao grupo:</p>
sudo usermod -aG tesseras $USER
</code></pre>
Faça logout e login novamente, depois inicie o daemon:</p>
sudo systemctl enable --now tesd
</code></pre>
O que o pacote inclui</h2>
Caminho</th> Descrição</th></tr></thead>

/usr/bin/tesd</code></td> Daemon do nó completo</td></tr>
/usr/bin/tes</code></td> Cliente CLI</td></tr>
/etc/tesseras/config.toml</code></td> Configuração padrão (marcado como backup)</td></tr>
/usr/lib/systemd/system/tesd.service</code></td> Unit systemd com hardening de segurança</td></tr>
/usr/lib/sysusers.d/tesseras.conf</code></td> Definição do usuário de sistema</td></tr>
/usr/lib/tmpfiles.d/tesseras.conf</code></td> Diretório de dados /var/lib/tesseras</code></td></tr>
Completions de shell</td> bash, zsh e fish</td></tr>
</tbody></table>
Detalhes do PKGBUILD</h2>
O PKGBUILD compila diretamente a partir do checkout git local em vez de baixar
um tarball. A variável de ambiente TESSERAS_ROOT</code> aponta o makepkg para a raiz
do workspace. O diretório target do Cargo é configurado para $srcdir/target</code>
para manter os artefatos de build dentro do sandbox do makepkg.</p>
O pacote depende apenas de sqlite</code> em tempo de execução e cargo</code> em tempo de
build.</p>
Atualizando</h2>
Depois de baixar novas mudanças, basta rodar just arch</code> novamente e reinstalar:</p>
git pull
just arch
sudo pacman -U packaging/archlinux/tesseras-*.pkg.tar.zst
</code></pre>


Fase 4: Deduplicacao de Armazenamento
2026-02-15T23:00:00+00:00
Quando multiplas tesseras compartilham a mesma foto, o mesmo clipe de audio ou
os mesmos dados de fragmento, a camada de armazenamento antiga mantinha copias
separadas de cada. Em um no armazenando milhares de tesseras para a rede, essa
duplicacao se acumula rapidamente. A Fase 4 continua com deduplicacao de
armazenamento: um armazenamento enderecavel por conteudo (CAS) que garante que
cada dado unico seja armazenado exatamente uma vez em disco, independentemente
de quantas tesseras o referenciam.</p>
O design e simples e comprovado: hash do conteudo com BLAKE3, usar o hash como
nome do arquivo e manter uma contagem de referencias no SQLite. Quando duas
tesseras incluem a mesma foto de 5 MB, um arquivo existe em disco com
refcount 2. Quando uma tessera e deletada, o refcount cai para 1 e o arquivo
permanece. Quando a ultima referencia e liberada, uma varredura periodica limpa
o orfao.</p>
O que foi construido</h2>
Migracao do esquema CAS</strong> (tesseras-storage/migrations/004_dedup.sql</code>) — Tres
novas tabelas:</p>

cas_objects</code> — rastreia cada objeto no armazenamento: hash BLAKE3 (chave
primaria), tamanho em bytes, contagem de referencias e timestamp de criacao</li>
blob_refs</code> — mapeia identificadores logicos de blobs (hash da tessera + hash
da memoria + nome do arquivo) para hashes CAS, substituindo a convencao antiga
de caminhos no sistema de arquivos</li>
fragment_refs</code> — mapeia identificadores logicos de fragmentos (hash da
tessera + indice do fragmento) para hashes CAS, substituindo o antigo layout
do diretorio fragments/</code></li>
</ul>
Indices nas colunas de hash garantem lookups O(1) durante leituras e contagem de
referencias.</p>
CasStore</strong> (tesseras-storage/src/cas.rs</code>) — O motor central de armazenamento
enderecavel por conteudo. Arquivos sao armazenados sob um diretorio de prefixo
de dois niveis: <raiz>/<prefixo-hex-2-chars>/<hash-completo>.blob</code>. O
armazenamento fornece cinco operacoes:</p>

put(hash, data)</code> — escreve dados em disco se ainda nao presente, incrementa o
refcount. Retorna se ocorreu um hit de deduplicacao.</li>
get(hash)</code> — le dados do disco pelo hash</li>
release(hash)</code> — decrementa o refcount. Se chegar a zero, o arquivo em disco
e deletado imediatamente.</li>
contains(hash)</code> — verifica existencia sem ler</li>
ref_count(hash)</code> — retorna a contagem de referencias atual</li>
</ul>
Todas as operacoes sao atomicas dentro de uma unica transacao SQLite. O refcount
e a fonte de verdade — se o refcount diz que o objeto existe, o arquivo deve
estar em disco.</p>
FsBlobStore com CAS</strong> (tesseras-storage/src/blob.rs</code>) — Reescrito para
delegar todo armazenamento ao CAS. Quando um blob e escrito, seu hash BLAKE3 e
computado e passado para cas.put()</code>. Uma linha em blob_refs</code> mapeia o caminho
logico (tessera + memoria + arquivo) para o hash CAS. Leituras buscam o hash CAS
via blob_refs</code> e leem de cas.get()</code>. Deletar uma tessera libera todas as suas
referencias de blob em uma unica transacao.</p>
FsFragmentStore com CAS</strong> (tesseras-storage/src/fragment.rs</code>) — Mesmo padrao
para fragmentos codificados com erasure coding. O checksum BLAKE3 de cada
fragmento ja e computado durante a codificacao Reed-Solomon, entao e usado
diretamente como chave CAS. A verificacao de fragmentos agora checa o hash CAS
ao inves de recomputar do zero — se o CAS diz que os dados estao intactos,
estao.</p>
Coletor de lixo sweep</strong> (cas.rs:sweep()</code>) — Uma passagem periodica de GC que
trata tres casos limite que o caminho normal de refcount nao consegue:</p>

Arquivos orfaos</strong> — arquivos em disco sem linha correspondente em
cas_objects</code>. Pode acontecer apos um crash durante escrita. Arquivos com
menos de 1 hora sao pulados (periodo de graca para escritas em andamento);
orfaos mais antigos sao deletados.</li>
Refcounts vazados</strong> — linhas em cas_objects</code> com refcount zero que nao
foram limpas (ex: se o processo morreu entre decrementar e deletar). Essas
linhas sao removidas.</li>
Idempotente</strong> — executar sweep duas vezes produz o mesmo resultado.</li>
</ol>
O sweep e conectado ao loop de reparo existente em tesseras-replication</code>, entao
roda automaticamente a cada 24 horas junto com as verificacoes de saude dos
fragmentos.</p>
Migracao do layout antigo</strong> (tesseras-storage/src/migration.rs</code>) — Uma
estrategia de migracao copy-first que move dados do layout antigo baseado em
diretorios (blobs/<tessera>/<memoria>/<arquivo></code> e
fragments/<tessera>/<indice>.shard</code>) para o CAS. A migracao:</p>

Verifica a versao de armazenamento em storage_meta</code> (versao 1 = layout
antigo, versao 2 = CAS)</li>
Percorre os diretorios antigos blobs/</code> e fragments/</code></li>
Computa hashes BLAKE3 e insere no CAS via put()</code> — duplicatas sao
automaticamente deduplicadas</li>
Cria entradas correspondentes em blob_refs</code> / fragment_refs</code></li>
Remove diretorios antigos somente apos todos os dados estarem seguros no CAS</li>
Atualiza a versao de armazenamento para 2</li>
</ol>
A migracao roda na inicializacao do daemon, e idempotente (segura para
re-executar) e reporta estatisticas: arquivos migrados, duplicatas encontradas,
bytes economizados.</p>
Metricas Prometheus</strong> (tesseras-storage/src/metrics.rs</code>) — Dez novas metricas
para observabilidade:</p>
Metrica</th> Descricao</th></tr></thead>

cas_objects_total</code></td> Total de objetos unicos no CAS</td></tr>
cas_bytes_total</code></td> Total de bytes armazenados</td></tr>
cas_dedup_hits_total</code></td> Numero de escritas que encontraram um objeto existente</td></tr>
cas_bytes_saved_total</code></td> Bytes economizados por deduplicacao</td></tr>
cas_gc_refcount_deletions_total</code></td> Objetos deletados quando refcount chegou a zero</td></tr>
cas_gc_sweep_orphans_cleaned_total</code></td> Arquivos orfaos removidos pelo sweep</td></tr>
cas_gc_sweep_leaked_refs_cleaned_total</code></td> Linhas de refcount vazadas limpas</td></tr>
cas_gc_sweep_skipped_young_total</code></td> Orfaos jovens pulados (periodo de graca)</td></tr>
cas_gc_sweep_duration_seconds</code></td> Tempo gasto no sweep GC</td></tr>
</tbody></table>
Testes baseados em propriedades</strong> — Dois testes proptest verificam invariantes
do CAS sob entradas aleatorias:</p>

refcount_matches_actual_refs</code> — apos N operacoes aleatorias de put/release, o
refcount sempre corresponde ao numero real de referencias pendentes</li>
cas_path_is_deterministic</code> — o mesmo hash sempre produz o mesmo caminho no
sistema de arquivos</li>
</ul>
Atualizacao de testes de integracao</strong> — Todos os testes de integracao em
tesseras-core</code>, tesseras-replication</code>, tesseras-embedded</code> e tesseras-cli</code>
atualizados para os novos construtores com CAS. Testes de deteccao de
adulteracao atualizados para funcionar com o layout de diretorio CAS.</p>
347 testes passam em todo o workspace. Clippy limpo com -D warnings</code>.</p>
Decisoes de arquitetura</h2>

BLAKE3 como chave CAS</strong>: o hash de conteudo que ja computamos para
verificacao de integridade serve tambem como chave de deduplicacao. Nenhuma
etapa adicional de hashing — o hash computado durante create</code> ou replicate</code>
e reutilizado como endereco CAS.</li>
Refcount SQLite ao inves de reflinks do sistema de arquivos</strong>: consideramos
usar copy-on-write no nivel do sistema de arquivos (reflinks em btrfs/XFS),
mas isso amarraria o Tesseras a sistemas de arquivos especificos. Refcounting
em SQLite funciona em qualquer sistema de arquivos, incluindo FAT32 em
pendrives baratos e ext4 em Raspberry Pis.</li>
Diretorios de prefixo hexadecimal de dois niveis</strong>: armazenar todos os
objetos CAS em um diretorio plano desaceleraria sistemas de arquivos com
milhoes de entradas. A divisao <prefixo 2 chars>/</code> limita qualquer diretorio
individual a ~65k entradas antes de um segundo nivel ser necessario. Isso
segue a abordagem usada pelo object store do Git.</li>
Periodo de graca para arquivos orfaos</strong>: o sweep GC pula arquivos com menos
de 1 hora para evitar deletar objetos sendo escritos por uma operacao
concorrente. Esta e uma escolha pragmatica — troca uma pequena janela de
potenciais orfaos por seguranca contra crashes sem exigir fsync ou commit de
duas fases.</li>
Migracao copy-first</strong>: a migracao copia dados para o CAS antes de remover
diretorios antigos. Se o processo for interrompido, os dados antigos
permanecem intactos e a migracao pode ser re-executada. Isso e mais lento que
mover arquivos mas garante zero perda de dados.</li>
Sweep no loop de reparo</strong>: ao inves de adicionar um timer separado de GC, o
sweep CAS aproveita o loop de reparo existente de 24 horas. Isso mantem o
daemon simples — um unico ciclo de manutencao em segundo plano cuida tanto da
saude dos fragmentos quanto da limpeza de armazenamento.</li>
</ul>
O que vem a seguir</h2>

Fase 4 continuacao</strong> — auditorias de seguranca, empacotamento para OS
(Alpine, Arch, Debian, OpenBSD, FreeBSD)</li>
Fase 5: Exploracao e Cultura</strong> — navegador publico de tesseras por
era/localizacao/tema/idioma, curadoria institucional, integracao genealogica
(FamilySearch, Ancestry), exportacao para midia fisica (M-DISC, microfilme,
papel livre de acido com QR), contexto assistido por IA</li>
</ul>
A deduplicacao de armazenamento completa a historia de eficiencia de
armazenamento do Tesseras. Um no que armazena fragmentos para milhares de
usuarios — comum para nos institucionais e nos completos sempre ligados — agora
paga o custo de disco apenas por dados unicos. Combinado com codificacao de
apagamento Reed-Solomon (que ja minimiza redundancia no nivel da rede), o
sistema alcanca armazenamento eficiente tanto nas camadas local quanto
distribuida.</p>


Fase 4: Onboarding de Nos Institucionais
2026-02-15T22:00:00+00:00
Uma rede P2P composta apenas por individuos e fragil. Discos rigidos morrem,
celulares sao perdidos, pessoas perdem interesse. A sobrevivencia a longo prazo
das memorias da humanidade depende de instituicoes — bibliotecas, arquivos,
museus, universidades — que medem seus tempos de vida em seculos. A Fase 4
continua com o onboarding de nos institucionais: organizacoes verificadas agora
podem prometer armazenamento, manter indices de busca e participar da rede com
uma identidade distinta.</p>
O design segue um principio de confiar mas verificar: instituicoes se
identificam via registros DNS TXT (o mesmo mecanismo usado por SPF, DKIM e DMARC
para email), prometem um orcamento de armazenamento e recebem isencoes de
reciprocidade para que possam armazenar fragmentos para outros sem esperar nada
em troca. Em contrapartida, a rede trata seus fragmentos como replicas de maior
qualidade e limita a dependencia excessiva de qualquer instituicao individual
atraves de restricoes de diversidade.</p>
O que foi construido</h2>
Bits de capacidade</strong> (tesseras-core/src/network.rs</code>) — Dois novos flags
adicionados ao bitfield Capabilities</code>: INSTITUTIONAL</code> (bit 7) e SEARCH_INDEX</code>
(bit 8). Um novo construtor institutional_default()</code> retorna o conjunto
completo de capacidades da Fase 2 mais esses dois bits e RELAY</code>. Nos normais
anunciam phase2_default()</code> que nao inclui flags institucionais. Testes de
roundtrip de serializacao verificam que os novos bits sobrevivem a codificacao
MessagePack.</p>
Tipos de busca</strong> (tesseras-core/src/search.rs</code>) — Tres novos tipos de dominio
para o subsistema de busca:</p>

SearchFilters</code> — parametros de consulta: memory_type</code>, visibility</code>,
language</code>, date_range</code>, geo</code> (bounding box), page</code>, page_size</code></li>
SearchHit</code> — um resultado individual: hash do conteudo mais um
MetadataExcerpt</code> (titulo, descricao, tipo de memoria, data de criacao,
visibilidade, idioma, tags)</li>
GeoFilter</code> — bounding box com min_lat</code>, max_lat</code>, min_lon</code>, max_lon</code> para
consultas espaciais</li>
</ul>
Todos os tipos derivam Serialize</code>/Deserialize</code> para transporte e
Clone</code>/Debug</code> para diagnostico.</p>
Configuracao institucional do daemon</strong> (tesd/src/config.rs</code>) — Uma nova secao
[institutional]</code> no TOML com domain</code> (o dominio DNS a verificar),
pledge_bytes</code> (compromisso de armazenamento em bytes) e search_enabled</code>
(toggle para o indice FTS5). O metodo to_dht_config()</code> agora define
Capabilities::institutional_default()</code> quando a configuracao institucional esta
presente, para que nos institucionais anunciem os bits de capacidade corretos em
respostas Pong.</p>
Verificacao DNS TXT</strong> (tesd/src/institutional.rs</code>) — Resolucao DNS assincrona
usando hickory-resolver</code> para verificar identidade institucional. O daemon
consulta registros TXT em _tesseras.<dominio></code> e analisa campos chave-valor:
v</code> (versao), node</code> (node ID em hexadecimal) e pledge</code> (compromisso de
armazenamento em bytes). A verificacao checa:</p>

Um registro TXT existe em _tesseras.<dominio></code></li>
O campo node</code> corresponde ao node ID do proprio daemon</li>
O campo pledge</code> esta presente e e valido</li>
</ol>
Na inicializacao, o daemon tenta a verificacao DNS. Se bem-sucedida, o no roda
com capacidades institucionais. Se falhar, o no registra um aviso e faz
downgrade para um no completo normal — sem crash, sem intervencao manual.</p>
Comando CLI de setup</strong> (tesseras-cli/src/institutional.rs</code>) — Um novo
subcomando institutional setup</code> que guia operadores pelo onboarding:</p>

Le a identidade do no a partir do diretorio de dados</li>
Solicita nome de dominio e tamanho do pledge</li>
Gera o registro DNS TXT exato a adicionar:
v=tesseras1 node=<hex> pledge=<bytes></code></li>
Escreve a secao institucional no arquivo de configuracao do daemon</li>
Imprime os proximos passos: adicionar o registro TXT, reiniciar o daemon</li>
</ol>
Indice de busca SQLite</strong> (tesseras-storage</code>) — Uma migracao
(003_institutional.sql</code>) que cria tres estruturas:</p>

search_content</code> — uma tabela virtual FTS5 para busca full-text sobre
metadados de tesseras (titulo, descricao, criador, tags, idioma)</li>
geo_index</code> — uma tabela virtual R-tree para consultas espaciais de bounding
box sobre latitude/longitude</li>
geo_map</code> — uma tabela de mapeamento ligando IDs de linhas do R-tree a hashes
de conteudo</li>
</ul>
O adaptador SqliteSearchIndex</code> implementa o port trait SearchIndex</code> com
index_tessera()</code> (inserir/atualizar) e search()</code> (consultar com filtros).
Consultas FTS5 suportam busca em linguagem natural; consultas geo usam
INTERSECT</code> do R-tree para lookups de bounding box. Resultados sao ranqueados
por score de relevancia do FTS5.</p>
A migracao tambem adiciona uma coluna is_institutional</code> a tabela reciprocity</code>,
tratada de forma idempotente via checagens pragma_table_info</code> (o
ALTER TABLE ADD COLUMN</code> do SQLite nao tem IF NOT EXISTS</code>).</p>
Bypass de reciprocidade</strong> (tesseras-replication/src/service.rs</code>) — Nos
institucionais sao isentos de checagens de reciprocidade. Quando
receive_fragment()</code> e chamado, se o node ID do remetente esta marcado como
institucional no ledger de reciprocidade, a checagem de saldo e ignorada
completamente. Isso significa que instituicoes podem armazenar fragmentos para
toda a rede sem precisar "ganhar" creditos primeiro — sua identidade verificada
por DNS e compromisso de armazenamento servem como credencial.</p>
Restricao de diversidade por tipo de no</strong>
(tesseras-replication/src/distributor.rs</code>) — Uma nova funcao
apply_institutional_diversity()</code> limita quantas replicas de uma unica tessera
podem ir para nos institucionais. O limite e ceil(fator_replicacao / 3.5)</code> —
com o padrao r=7</code>, no maximo 2 de 7 replicas vao para instituicoes. Isso impede
que a rede se torne dependente de um pequeno numero de grandes instituicoes: se
os servidores de uma universidade cairem, pelo menos 5 replicas permanecem em
nos independentes.</p>
Extensoes de mensagens DHT</strong> (tesseras-dht/src/message.rs</code>) — Duas novas
variantes de mensagem:</p>
Mensagem</th> Proposito</th></tr></thead>

Search</code></td> Cliente envia string de consulta, filtros e numero da pagina</td></tr>
SearchResult</code></td> No institucional responde com resultados e contagem total</td></tr>
</tbody></table>
A funcao encode()</code> foi trocada de serializacao MessagePack posicional para
nomeada (rmp_serde::to_vec_named</code>) para lidar corretamente com campos opcionais
de SearchFilters</code> — a codificacao posicional quebra quando
skip_serializing_if</code> omite campos.</p>
Metricas Prometheus</strong> (tesd/src/metrics.rs</code>) — Oito metricas especificas
institucionais:</p>

tesseras_institutional_pledge_bytes</code> — compromisso de armazenamento
configurado</li>
tesseras_institutional_stored_bytes</code> — bytes realmente armazenados</li>
tesseras_institutional_pledge_utilization_ratio</code> — razao armazenado/prometido</li>
tesseras_institutional_peers_served</code> — peers unicos que receberam fragmentos</li>
tesseras_institutional_search_index_total</code> — tesseras no indice de busca</li>
tesseras_institutional_search_queries_total</code> — consultas de busca recebidas</li>
tesseras_institutional_dns_verification_status</code> — 1 se verificado por DNS, 0
caso contrario</li>
tesseras_institutional_dns_verification_last</code> — timestamp Unix da ultima
verificacao</li>
</ul>
Testes de integracao</strong> — Dois testes em
tesseras-replication/tests/integration.rs</code>:</p>

institutional_peer_bypasses_reciprocity</code> — verifica que um peer institucional
com deficit massivo (-999.999 de saldo) ainda pode armazenar fragmentos,
enquanto um peer nao institucional com o mesmo deficit e rejeitado</li>
institutional_node_accepts_fragment_despite_deficit</code> — teste async completo
usando ReplicationService</code> com DHT, fragment store, reciprocity ledger e blob
store mockados: envia um fragmento de um remetente institucional e verifica
que e aceito</li>
</ul>
322 testes passam em todo o workspace. Clippy limpo com -D warnings</code>.</p>
Decisoes de arquitetura</h2>

DNS TXT ao inves de PKI ou blockchain</strong>: DNS e universalmente implantado,
universalmente compreendido e ja usado para verificacao de dominio (SPF, DKIM,
Let's Encrypt). Instituicoes ja gerenciam DNS. Nenhuma autoridade
certificadora, nenhum token, nenhuma transacao on-chain — apenas um registro
TXT. Se uma instituicao perder controle de seu dominio, a verificacao
naturalmente falha na proxima checagem.</li>
Degradacao graciosa em falha DNS</strong>: se a verificacao DNS falha na
inicializacao, o daemon faz downgrade para um no completo normal ao inves de
recusar iniciar. Isso previne incidentes operacionais — uma misconfiguracao
DNS nao deveria tirar um no do ar.</li>
Limite de diversidade em ceil(r / 3.5)</code></strong>: com r=7</code>, no maximo 2 replicas
vao para instituicoes. Isso e conservador — garante que a rede nunca dependa
de instituicoes para quorum majoritario, enquanto ainda se beneficia de sua
capacidade de armazenamento e uptime.</li>
Codificacao MessagePack nomeada</strong>: trocar de codificacao posicional para
nomeada adiciona ~15% de overhead por mensagem mas elimina uma classe de bugs
de serializacao quando campos opcionais estao presentes. O DHT nao e limitado
por largura de banda no nivel de mensagem, entao o tradeoff vale a pena.</li>
Isencao de reciprocidade ao inves de concessao de creditos</strong>: ao inves de
dar as instituicoes um saldo inicial grande de creditos (que e arbitrario e
precisa de ajuste), isentamos completamente. Sua identidade verificada por DNS
e compromisso publico de armazenamento substituem o mecanismo de reciprocidade
bilateral.</li>
FTS5 + R-tree no SQLite</strong>: busca full-text e indexacao espacial sao
embutidas no SQLite como extensoes carregaveis. Nenhum motor de busca externo
(Elasticsearch, Meilisearch) necessario. Isso mantem o deploy como um unico
binario com um unico arquivo de banco de dados — critico para operadores
institucionais que podem nao ter uma equipe de DevOps.</li>
</ul>
O que vem a seguir</h2>

Fase 4 continuacao</strong> — deduplicacao de armazenamento (armazenamento
enderecavel por conteudo com BLAKE3), auditorias de seguranca, empacotamento
para OS (Alpine, Arch, Debian, OpenBSD, FreeBSD)</li>
Fase 5: Exploracao e Cultura</strong> — navegador publico de tesseras por
era/localizacao/tema/idioma, curadoria institucional, integracao genealogica
(FamilySearch, Ancestry), exportacao para midia fisica (M-DISC, microfilme,
papel livre de acido com QR), contexto assistido por IA</li>
</ul>
O onboarding institucional fecha uma lacuna critica no modelo de preservacao do
Tesseras. Nos individuais fornecem resiliencia de base — milhares de
dispositivos ao redor do globo, cada um armazenando alguns fragmentos. Nos
institucionais fornecem ancoragem — organizacoes com infraestrutura
profissional, armazenamento redundante e horizontes operacionais de multiplas
decadas. Juntos, formam uma rede onde memorias podem sobreviver tanto a
dispositivos individuais quanto a instituicoes individuais.</p>


Fase 4: Tuning de Performance
2026-02-15T20:00:00+00:00
Uma rede P2P que atravessa NATs mas engasga com seu proprio I/O nao serve de
muito. A Fase 4 continua com tuning de performance: centralizacao da
configuracao do banco de dados, cache de blobs de fragmentos em memoria,
gerenciamento de ciclo de vida de conexoes QUIC e eliminacao de leituras
desnecessarias de disco no hot path de atestacao.</p>
O principio orientador foi o mesmo do resto do Tesseras: fazer a coisa mais
simples que realmente funciona. Sem alocadores customizados, sem estruturas de
dados lock-free, sem complexidade prematura. Um StorageConfig</code> centralizado, um
cache LRU, um reaper de conexoes e uma correcao pontual para evitar reler blobs
que ja tinham checksum calculado.</p>
O que foi construido</h2>
Configuracao SQLite centralizada</strong> (tesseras-storage/src/database.rs</code>) — Um
novo struct StorageConfig</code> e funcoes open_database()</code> / open_in_memory()</code> que
aplicam todos os pragmas SQLite em um unico lugar: journal mode WAL, foreign
keys, modo synchronous (NORMAL por padrao, FULL para hardware instavel como
RPi + cartao SD), busy timeout, tamanho do cache de paginas e intervalo de
autocheckpoint WAL. Anteriormente, cada ponto de chamada abria uma conexao e
aplicava pragmas ad hoc. Agora o daemon, CLI e testes passam todos pelo mesmo
caminho. 7 testes cobrindo foreign keys, busy timeout, journal mode, migracoes,
modos synchronous e criacao de arquivos WAL em disco.</p>
Cache LRU de fragmentos</strong> (tesseras-storage/src/cache.rs</code>) — Um
CachedFragmentStore</code> que envolve qualquer FragmentStore</code> com um cache LRU
ciente de bytes. Blobs de fragmentos sao cacheados na leitura e invalidados na
escrita ou exclusao. Quando o cache excede seu limite de bytes configurado, as
entradas menos recentemente usadas sao removidas. O cache e transparente: ele
proprio implementa FragmentStore</code>, entao o resto da pilha nao sabe que esta la.
Metricas Prometheus opcionais rastreiam hits, misses e uso atual de bytes. 3
testes: hit no cache evita leitura interna, store invalida cache, remocao quando
excede bytes maximos.</p>
Metricas Prometheus de storage</strong> (tesseras-storage/src/metrics.rs</code>) — Um
struct StorageMetrics</code> com tres contadores/gauges: fragment_cache_hits</code>,
fragment_cache_misses</code> e fragment_cache_bytes</code>. Registrado no registry
Prometheus e conectado ao cache de fragmentos via with_metrics()</code>.</p>
Correcao do hot path de atestacao</strong> (tesseras-replication/src/service.rs</code>) —
O fluxo de atestacao anteriormente lia cada blob de fragmento do disco e
recalculava seu checksum BLAKE3. Como list_fragments()</code> ja retorna FragmentId</code>
com um checksum armazenado, a correcao e trivial: usar frag.checksum</code> ao inves
de blake3::hash(&data)</code>. Isso elimina uma leitura de disco por fragmento
durante atestacao — para uma tessera com 100 fragmentos, sao 100 leituras a
menos. Um teste com expect_read_fragment().never()</code> verifica que nenhuma
leitura de blob acontece durante atestacao.</p>
Ciclo de vida do pool de conexoes QUIC</strong>
(tesseras-net/src/quinn_transport.rs</code>) — Um struct PoolConfig</code> controlando
maximo de conexoes, timeout de inatividade e intervalo do reaper.
PooledConnection</code> envolve cada quinn::Connection</code> com um timestamp
last_used</code>. Quando o pool atinge capacidade maxima, a conexao inativa mais
antiga e removida antes de abrir uma nova. Uma tarefa reaper em background
(Tokio spawn) periodicamente fecha conexoes que ficaram inativas alem do
timeout. 4 novas metricas de pool: tesseras_conn_pool_size</code>, pool_hits_total</code>,
pool_misses_total</code>, pool_evictions_total</code>.</p>
Integracao no daemon</strong> (tesd/src/config.rs</code>, main.rs</code>) — Uma nova secao
[performance]</code> na configuracao TOML com campos para tamanho de cache SQLite,
modo synchronous, busy timeout, tamanho de cache de fragmentos, maximo de
conexoes, timeout de inatividade e intervalo do reaper. O main()</code> do daemon
agora chama open_database()</code> com o StorageConfig</code> configurado, envolve
FsFragmentStore</code> com CachedFragmentStore</code> e vincula QUIC com o PoolConfig</code>
configurado. A dependencia direta de rusqlite</code> foi removida do crate do daemon.</p>
Migracao do CLI</strong> (tesseras-cli/src/commands/init.rs</code>, create.rs</code>) — Ambos
os comandos init</code> e create</code> agora usam tesseras_storage::open_database()</code> com
o StorageConfig</code> padrao ao inves de abrir conexoes rusqlite</code> diretamente. A
dependencia de rusqlite</code> foi removida do crate do CLI.</p>
Decisoes de arquitetura</h2>

Padrao decorator para cache</strong>: CachedFragmentStore</code> envolve
Box<dyn FragmentStore></code> e implementa FragmentStore</code> ele proprio. Isso
significa que cache e opt-in, composavel e invisivel para consumidores. O
daemon habilita; testes podem pular.</li>
Remocao ciente de bytes</strong>: o cache LRU rastreia bytes totais, nao contagem
de entradas. Blobs de fragmentos variam muito em tamanho (um fragmento de
texto de 4KB vs um shard de foto de 2MB), entao contar entradas daria uma
visao enganosa do uso de memoria.</li>
Sem crate de pool de conexoes</strong>: ao inves de trazer uma biblioteca generica
de pool, o pool de conexoes e um wrapper fino sobre
DashMap<SocketAddr, PooledConnection></code> com um reaper Tokio. Conexoes QUIC sao
multiplexadas, entao o "pool" e realmente sobre gerenciamento de ciclo de vida
(limpeza de inativos, maximo de conexoes) e nao sobre emprestar/devolver.</li>
Checksums armazenados ao inves de releituras</strong>: a correcao de atestacao e
intencionalmente minima — uma linha alterada, uma leitura de disco removida
por fragmento. Os checksums ja estavam armazenados no SQLite por
store_fragment()</code>, apenas nao estavam sendo usados.</li>
Configuracao centralizada de pragmas</strong>: um unico struct StorageConfig</code>
substitui chamadas PRAGMA</code> espalhadas. O flag sqlite_synchronous_full</code>
existe especificamente para implantacoes em Raspberry Pi onde o kernel pode
crashar e perder transacoes WAL nao checkpointadas.</li>
</ul>
O que vem a seguir</h2>

Fase 4 continuacao</strong> — Shamir's Secret Sharing para herdeiros, tesseras
seladas (criptografia time-lock), auditorias de seguranca, onboarding de nos
institucionais, deduplicacao de storage, empacotamento para OS</li>
Fase 5: Exploracao e Cultura</strong> — navegador publico de tesseras por
era/localizacao/tema/idioma, curadoria institucional, integracao genealogica,
exportacao para midia fisica (M-DISC, microfilme, papel livre de acido com QR)</li>
</ul>
Com tuning de performance implementado, Tesseras lida com o caso comum de forma
eficiente: leituras de fragmentos acertam o cache LRU, atestacao pula I/O de
disco, conexoes QUIC inativas sao removidas automaticamente e o SQLite e
configurado consistentemente em toda a pilha. Os proximos passos focam em
funcionalidades criptograficas (Shamir, time-lock) e hardening para implantacao
em producao.</p>


Fase 4: Verificar Sem Instalar Nada
2026-02-15T20:00:00+00:00
Confiança não deveria exigir instalação de software. Se alguém te envia uma
tessera — um pacote de memórias preservadas — você deveria poder verificar que é
genuína e não foi modificada sem baixar um app, criar uma conta, ou confiar em
um servidor. É isso que o tesseras-wasm</code> entrega: arraste um arquivo tessera
para uma página web, e a verificação criptográfica acontece inteiramente no seu
navegador.</p>
O que foi construído</h2>
tesseras-wasm</strong> — Um crate Rust que compila para WebAssembly via wasm-pack,
expondo quatro funções stateless para JavaScript. O crate depende do
tesseras-core</code> para parsing do manifesto e chama primitivas criptográficas
diretamente (blake3, ed25519-dalek) ao invés de depender do tesseras-crypto</code>,
que puxa bibliotecas pós-quânticas baseadas em C que não compilam para
wasm32-unknown-unknown</code>.</p>
parse_manifest</code> recebe os bytes brutos do MANIFEST (texto UTF-8 plano, não
MessagePack), delega para tesseras_core::manifest::Manifest::parse()</code>, e
retorna uma string JSON com a chave pública Ed25519 do criador, caminhos dos
arquivos de assinatura, e uma lista de arquivos com seus hashes BLAKE3
esperados, tamanhos e tipos MIME. Structs internas (ManifestJson</code>,
CreatorPubkey</code>, SignatureFiles</code>, FileEntry</code>) são serializadas com serde_json.
Os campos de chave pública ML-DSA e arquivo de assinatura estão presentes no
contrato JSON mas definidos como null</code> — prontos para quando a assinatura
pós-quântica for implementada no lado nativo.</p>
hash_blake3</code> computa um hash BLAKE3 de bytes arbitrários e retorna uma string
hexadecimal de 64 caracteres. É chamada uma vez por arquivo na tessera para
verificar integridade contra o MANIFEST.</p>
verify_ed25519</code> recebe uma mensagem, uma assinatura de 64 bytes e uma chave
pública de 32 bytes, constrói uma ed25519_dalek::VerifyingKey</code>, e retorna se a
assinatura é válida. A validação de comprimento retorna erros descritivos
("Ed25519 public key must be 32 bytes") ao invés de causar panic.</p>
verify_ml_dsa</code> é um stub que retorna um erro explicando que verificação ML-DSA
ainda não está disponível. Isso é deliberado: o crate ml-dsa</code> no crates.io está
na v0.1.0-rc.7 (pré-release), e o tesseras-crypto</code> usa pqcrypto-dilithium</code>
(CRYSTALS-Dilithium baseado em C) que é incompatível em nível de bytes com FIPS
204 ML-DSA. Ambos os lados precisam usar a mesma implementação em Rust puro
antes que a verificação cruzada funcione. Verificação Ed25519 é suficiente —
toda tessera é assinada com Ed25519.</p>
Todas as quatro funções usam um padrão de duas camadas para testabilidade:
funções internas retornam Result<T, String></code> e são testadas nativamente,
enquanto wrappers finos #[wasm_bindgen]</code> convertem erros para JsError</code>. Isso
evita que JsError::new()</code> cause panic em targets não-WASM durante os testes.</p>
O binário WASM compilado tem 109 KB bruto e 44 KB com gzip — bem abaixo do
orçamento de 200 KB. O wasm-opt aplica otimização -Oz</code> após o wasm-pack
compilar com opt-level = "z"</code>, LTO e uma única unidade de codegen.</p>
@tesseras/verify</strong> — Um pacote npm TypeScript (crates/tesseras-wasm/js/</code>) que
orquestra a verificação no lado do navegador. A API pública é uma única função:</p>
async function verifyTessera(
  archive: Uint8Array,
  onProgress?: (current: number, total: number, file: string) => void
): Promise<VerificationResult>
</code></pre>
O tipo VerificationResult</code> fornece tudo que uma UI precisa: validade geral,
hash da tessera, chaves públicas do criador, status das assinaturas
(valid/invalid/missing para Ed25519 e ML-DSA), resultados de integridade por
arquivo com hashes esperados e reais, uma lista de arquivos inesperados não
presentes no MANIFEST, e um array de erros.</p>
A descompactação de arquivos (unpack.ts</code>) lida com três formatos: tar
comprimido com gzip (detectado pelos magic bytes \x1f\x8b</code>, descomprimido com
fflate e depois parseado como tar), ZIP (magic PK\x03\x04</code>, descompactado com
unzipSync</code> do fflate), e tar bruto (ustar</code> no offset 257). Uma função
normalizePath</code> remove o prefixo tessera-<hash>/</code> para que os caminhos internos
correspondam às entradas do MANIFEST.</p>
A verificação roda em um Web Worker (worker.ts</code>) para manter a thread da UI
responsiva. O worker inicializa o módulo WASM, descompacta o arquivo, parseia o
MANIFEST, verifica a assinatura Ed25519 contra a chave pública do criador,
depois faz hash de cada arquivo com BLAKE3 e compara com os valores esperados.
Mensagens de progresso são transmitidas de volta para a thread principal após
cada arquivo. Se qualquer assinatura é inválida, a verificação para
imediatamente sem fazer hash dos arquivos — falhando rápido na verificação mais
crítica.</p>
O arquivo é transferido para o worker com zero-copy
(worker.postMessage({ type: "verify", archive }, [archive.buffer])</code>) para
evitar duplicar arquivos de tessera potencialmente grandes na memória.</p>
Pipeline de build</strong> — Três novos targets no justfile: wasm-build</code> executa
wasm-pack com --target web --release</code> e otimiza com wasm-opt; wasm-size</code>
reporta o tamanho do binário bruto e com gzip; test-wasm</code> executa a suíte de
testes nativos.</p>
Testes</strong> — 9 testes unitários nativos cobrem hashing BLAKE3 (entrada vazia,
valor conhecido), verificação Ed25519 (assinatura válida, assinatura inválida,
chave errada, comprimento de chave inválido), e parsing do MANIFEST (manifesto
válido, UTF-8 inválido, lixo). 3 testes de integração WASM rodam em Chrome
headless via wasm-pack test --headless --chrome</code>, verificando que
hash_blake3</code>, verify_ed25519</code> e parse_manifest</code> funcionam corretamente quando
compilados para wasm32-unknown-unknown</code>.</p>
Decisões de arquitetura</h2>

Sem dependência do tesseras-crypto</strong>: o crate WASM chama blake3 e
ed25519-dalek diretamente. O tesseras-crypto</code> depende do pqcrypto-kyber</code>
(ML-KEM baseado em C via pqcrypto-traits) que requer um toolchain de
compilador C e não tem target wasm32. Dependendo apenas de crates Rust puros,
o build WASM tem zero dependências C e compila sem problemas para WebAssembly.</li>
ML-DSA adiado, não fingido</strong>: ao invés de silenciosamente pular a
verificação pós-quântica, o stub retorna um erro explícito. Isso garante que
se uma tessera contiver uma assinatura ML-DSA, o resultado da verificação
reportará ml_dsa: "missing"</code> ao invés de fingir que foi verificada. O
orquestrador JS lida com isso graciosamente — uma tessera é válida se Ed25519
passar e ML-DSA estiver ausente (ainda não implementado em nenhum dos lados).</li>
Padrão de função interna</strong>: JsError</code> não pode ser construído em targets
não-WASM (causa panic). Dividir cada função em
foo_inner() -> Result<T, String></code> e foo() -> Result<T, JsError></code> permite que
a suíte de testes nativa exercite toda a lógica sem tocar em tipos JavaScript.
Os testes de integração WASM em Chrome headless testam a superfície completa
do #[wasm_bindgen]</code>.</li>
Isolamento em Web Worker</strong>: operações criptográficas (especialmente BLAKE3
sobre arquivos de mídia grandes) podem levar centenas de milissegundos. Rodar
em um Worker previne travamentos na UI. O protocolo de progresso com streaming
({ type: "progress", current, total, file }</code>) permite que a UI mostre uma
barra de progresso durante a verificação de tesseras com muitos arquivos.</li>
Transferência zero-copy</strong>: archive.buffer</code> é transferido para o Worker, não
copiado. Para um arquivo tessera de 50 MB, isso evita dobrar o uso de memória
durante a verificação.</li>
MANIFEST em texto plano, não MessagePack</strong>: o crate WASM parseia o mesmo
formato de MANIFEST em texto plano que o CLI. Isso é por design — o MANIFEST é
a Pedra de Rosetta da tessera, legível por qualquer pessoa com um editor de
texto. A dependência rmp-serde</code> no Cargo.toml não é usada e será removida.</li>
</ul>
O que vem a seguir</h2>

Fase 4: Resiliência e Escala</strong> — Empacotamento para sistemas operacionais
(Alpine, Arch, Debian, FreeBSD, OpenBSD), CI no SourceHut e GitHub Actions,
auditorias de segurança, explorador de tesseras no navegador em tesseras.net
usando @tesseras/verify</li>
Fase 5: Exploração e Cultura</strong> — Navegador público de tesseras por
era/localização/tema/idioma, curadoria institucional, integração com
genealogia, exportação para mídia física (M-DISC, microfilme, papel livre de
ácido com QR)</li>
</ul>
A verificação não exige mais confiança em software. Um arquivo tessera arrastado
para um navegador é verificado com o mesmo rigor criptográfico do CLI — mesmos
hashes BLAKE3, mesmas assinaturas Ed25519, mesmo parser de MANIFEST. A diferença
é que agora qualquer pessoa pode fazer isso.</p>


Fase 4: Furando NATs
2026-02-15T18:00:00+00:00
A maioria dos dispositivos das pessoas ficam atras de um NAT — um tradutor de
enderecos de rede que permite acessar a internet mas impede conexoes de entrada.
Para uma rede P2P, isso e um problema existencial: se dois nos atras de NATs nao
conseguem se comunicar, a rede se fragmenta. A Fase 4 continua com uma pilha
completa de travessia de NAT: descoberta via STUN, hole punching coordenado e
fallback por relay.</p>
A abordagem segue o mesmo padrao da maioria dos sistemas P2P consolidados
(WebRTC, BitTorrent, IPFS): tente a opcao mais barata primeiro, escale apenas
quando necessario. Conectividade direta nao custa nada. Hole punching custa
alguns pacotes coordenados. Relay custa largura de banda sustentada de um
terceiro. Tesseras tenta nessa ordem.</p>
O que foi construido</h2>
Classificacao NatType</strong> (tesseras-core/src/network.rs</code>) — Um novo enum
NatType</code> (Public, Cone, Symmetric, Unknown) adicionado a camada de dominio
core. Esse tipo e compartilhado por toda a pilha: o cliente STUN o escreve, o
DHT o divulga em mensagens Pong, e o coordenador de punch o le para decidir se
hole punching vale a pena tentar (Cone-para-Cone funciona ~80% das vezes;
Symmetric-para-Symmetric quase nunca funciona).</p>
Cliente STUN</strong> (tesseras-net/src/stun.rs</code>) — Uma implementacao STUN minima
(RFC 5389 Binding Request/Response) que descobre o endereco externo de um no. O
codec codifica requisicoes de 20 bytes com um ID de transacao aleatorio e
decodifica respostas XOR-MAPPED-ADDRESS. A funcao discover_nat()</code> consulta
multiplos servidores STUN em paralelo (Google, Cloudflare por padrao), compara
os enderecos mapeados e classifica o tipo de NAT:</p>

Mesmo IP e porta de todos os servidores → Public</strong> (sem NAT)</li>
Mesmo endereco mapeado de todos os servidores → Cone</strong> (hole punching
funciona)</li>
Enderecos mapeados diferentes → Symmetric</strong> (hole punching nao confiavel)</li>
Sem respostas → Unknown</strong></li>
</ul>
Retentativas com backoff exponencial e timeouts configuraveis. 12 testes
cobrindo roundtrips de codec, todos os caminhos de classificacao e consultas
async em loopback.</p>
Coordenacao de punch assinada</strong> (tesseras-net/src/punch.rs</code>) — Assinatura e
verificacao Ed25519 para mensagens PunchIntro</code>, RelayRequest</code> e
RelayMigrate</code>. Cada introducao e assinada pelo iniciador com uma janela de
timestamp de 30 segundos, prevenindo ataques de reflexao (onde um atacante
reproduz uma introducao antiga para redirecionar trafego). O formato do payload
e target || external_addr || timestamp</code> — alterar qualquer campo invalida a
assinatura. 6 testes unitarios mais 3 testes baseados em propriedades com
proptest (IDs de no, portas e tokens de sessao arbitrarios).</p>
Gerenciador de sessoes de relay</strong> (tesseras-net/src/relay.rs</code>) — Gerencia
sessoes de relay UDP transparente entre nos com NAT. Cada sessao tem um token
aleatorio de 16 bytes; os nos prefixam seus pacotes com o token, o relay remove
e encaminha. Funcionalidades:</p>

Encaminhamento bidirecional (A→R→B e B→R→A)</li>
Limite de taxa: 256 KB/s para nos reciprocos, 64 KB/s para nao reciprocos</li>
Duracao maxima de 10 minutos para sessoes bootstrap (nao reciprocas)</li>
Migracao de endereco: quando o IP de um no muda (Wi-Fi para celular), um
RelayMigrate</code> assinado atualiza a sessao sem derruba-la</li>
Limpeza por inatividade com timeout configuravel</li>
8 testes unitarios mais 2 testes baseados em propriedades</li>
</ul>
Extensoes de mensagens DHT</strong> (tesseras-dht/src/message.rs</code>) — Sete novas
variantes de mensagem adicionadas ao protocolo DHT:</p>
Mensagem</th> Proposito</th></tr></thead>

PunchIntro</code></td> "Quero conectar ao no X, aqui esta meu endereco externo assinado"</td></tr>
PunchRequest</code></td> O introdutor encaminha a requisicao ao destino</td></tr>
PunchReady</code></td> O destino confirma prontidao, envia seu endereco externo</td></tr>
RelayRequest</code></td> "Crie uma sessao de relay para o no X"</td></tr>
RelayOffer</code></td> O relay responde com seu endereco e token de sessao</td></tr>
RelayClose</code></td> Encerrar uma sessao de relay</td></tr>
RelayMigrate</code></td> Atualizar sessao apos mudanca de rede</td></tr>
</tbody></table>
A mensagem Pong</code> foi estendida com metadados NAT: nat_type</code>,
relay_slots_available</code> e relay_bandwidth_used_kbps</code>. Todos os novos campos
usam #[serde(default)]</code> para compatibilidade retroativa — nos antigos ignoram o
que nao reconhecem, nos novos usam defaults. 9 novos testes de roundtrip de
serializacao.</p>
Trait NatHandler e dispatch</strong> (tesseras-dht/src/engine.rs</code>) — Uma nova trait
async NatHandler</code> (5 metodos) injetada no engine DHT, seguindo o mesmo padrao
de injecao de dependencia do ReplicationHandler</code> existente. O loop de dispatch
de mensagens do engine agora roteia todas as mensagens punch/relay para o
handler. Isso mantem o engine DHT agnóstico ao protocolo enquanto permite que a
logica de travessia de NAT viva em tesseras-net</code>.</p>
Tipos de reconexao mobile</strong> (tesseras-embedded/src/reconnect.rs</code>) — Uma
maquina de estados de reconexao em tres fases para dispositivos moveis:</p>

QuicMigration</strong> (0-2s) — tenta migracao de conexao QUIC para todos os peers
ativos</li>
ReStun</strong> (2-5s) — redescobre endereco externo via STUN</li>
ReEstablish</strong> (5-10s) — reconecta peers que a migracao nao conseguiu salvar</li>
</ol>
Peers sao reconectados em ordem de prioridade: nos bootstrap primeiro, depois
nos que guardam nossos fragmentos, depois nos cujos fragmentos guardamos, depois
vizinhos DHT gerais. Uma nova variante de evento NetworkChanged</code> foi adicionada
ao stream de eventos FFI para que o app Flutter possa mostrar progresso de
reconexao.</p>
Configuracao NAT do daemon</strong> (tesd/src/config.rs</code>) — Uma nova secao [nat]</code>
na configuracao TOML com lista de servidores STUN, toggle de relay, maximo de
sessoes relay, limites de largura de banda (reciproco vs bootstrap) e timeout de
inatividade. Todos os campos tem defaults sensiveis; relay e desabilitado por
padrao.</p>
Metricas Prometheus</strong> (tesseras-net/src/metrics.rs</code>) — 16 metricas em quatro
subsistemas:</p>

STUN</strong>: requisicoes, falhas, histograma de latencia</li>
Punch</strong>: tentativas/sucessos/falhas (por par de tipo NAT), histograma de
latencia</li>
Relay</strong>: sessoes ativas, sessoes totais, bytes encaminhados, timeouts por
inatividade, hits de rate limit</li>
Reconexao</strong>: mudancas de rede, tentativas/sucessos por fase, histograma de
duracao</li>
</ul>
6 testes verificando registro, incremento, cardinalidade de labels e deteccao de
registro duplo.</p>
Testes de integracao</strong> — Dois testes end-to-end usando MemTransport</code> (rede
simulada em memoria):</p>

punch_integration.rs</code> — Fluxo completo de hole-punch com 3 nos: A envia
PunchIntro</code> assinado ao introdutor I, I verifica e encaminha PunchRequest</code> a
B, B verifica a assinatura original e envia PunchReady</code> de volta, A e B
trocam mensagens diretamente. Tambem testa que uma assinatura invalida e
corretamente rejeitada.</li>
relay_integration.rs</code> — Fluxo completo de relay com 3 nos: A solicita relay
de R, R cria sessao e envia RelayOffer</code> a ambos os peers, A e B trocam
pacotes prefixados com token atraves de R, A migra para um novo endereco no
meio da sessao, A fecha a sessao, e o teste verifica que a sessao e encerrada
e encaminhamento posterior falha.</li>
</ul>
Testes de propriedade</strong> — 7 testes baseados em proptest cobrindo: roundtrips
de assinatura para todos os tres tipos de mensagem assinada (IDs de no, portas e
tokens arbitrarios), determinismo de classificacao NAT (mesmas entradas sempre
produzem mesma saida), validade de binding request STUN, unicidade de tokens de
sessao, e rejeicao de pacotes curtos pelo relay.</p>
Alvos Justfile</strong> — just test-nat</code> executa todos os testes de travessia NAT em
tesseras-net</code> e tesseras-dht</code>. just test-chaos</code> e um placeholder para futuros
testes de caos com Docker Compose e tc netem</code>.</p>
Decisoes de arquitetura</h2>

STUN ao inves de TURN</strong>: implementamos STUN (descoberta) e relay customizado
ao inves de TURN completo. TURN requer alocacao autenticada e foi projetado
para relay de midia; nosso relay e mais simples — encaminhamento UDP com
prefixo de token e limites de taxa. Isso mantem o protocolo minimo e evita
depender de servidores TURN externos.</li>
Assinaturas em introducoes</strong>: cada PunchIntro</code> e assinado pelo iniciador.
Sem isso, um atacante poderia enviar introducoes forjadas para redirecionar as
tentativas de hole-punch de um no para um endereco controlado pelo atacante
(ataque de reflexao). A janela de timestamp de 30 segundos limita replay.</li>
Tiers reciprocos de largura de banda</strong>: nos relay dao 4x mais largura de
banda (256 vs 64 KB/s) para peers com boas pontuacoes de reciprocidade. Isso
incentiva nos a armazenar fragmentos para outros — se voce contribui, recebe
melhor servico de relay quando precisa.</li>
Extensao Pong retrocompativel</strong>: novos campos NAT em Pong</code> usam
#[serde(default)]</code> e Option<T></code>. Nos antigos que nao entendem esses campos
simplesmente os pulam durante deserializacao. Nenhum bump de versao de
protocolo necessario.</li>
NatHandler como trait async</strong>: a logica de travessia NAT e injetada no
engine DHT via trait, assim como ReplicationHandler</code>. Isso mantem o engine
DHT focado em roteamento e gerenciamento de peers, e permite que a
implementacao NAT seja trocada ou desabilitada sem tocar no codigo core do
DHT.</li>
</ul>
O que vem a seguir</h2>

Fase 4 continuacao</strong> — tuning de performance (pooling de conexoes, cache de
fragmentos, SQLite WAL), auditorias de seguranca, onboarding de nos
institucionais, empacotamento para OS</li>
Fase 5: Exploracao e Cultura</strong> — navegador publico de tesseras por
era/localizacao/tema/idioma, curadoria institucional, integracao genealogica,
exportacao para midia fisica (M-DISC, microfilme, papel livre de acido com QR)</li>
</ul>
Com travessia de NAT, Tesseras pode conectar nos independentemente de sua
topologia de rede. Nos publicos conversam diretamente. Nos com NAT Cone furam
com ajuda de um introdutor. Nos com NAT Symmetric ou firewalled usam relay
atraves de peers voluntarios. A rede se adapta ao mundo real, onde a maioria dos
dispositivos esta atras de um NAT e as condicoes de rede mudam constantemente.</p>


CLI Encontra a Rede: Comandos Publish, Fetch e Status
2026-02-15T00:00:00+00:00
Até agora o CLI operava isoladamente: criar uma tessera, verificar, exportar,
listar o que você tem. Tudo ficava na sua máquina. Com esta atualização, o tes</code>
ganha três comandos que fazem a ponte entre o armazenamento local e a rede P2P —
publish</code>, fetch</code> e status</code> — comunicando-se com um tesd</code> em execução através
de um socket Unix.</p>
O que foi construído</h2>
Crate tesseras-rpc</code></strong> — Um novo crate compartilhado entre CLI e daemon.
Define o protocolo RPC usando serialização MessagePack com enquadramento
prefixado por tamanho (cabeçalho big-endian de 4 bytes, máximo de 64 MiB). Três
tipos de requisição (Publish</code>, Fetch</code>, Status</code>) e suas respostas
correspondentes. Um DaemonClient</code> síncrono gerencia a conexão do socket Unix
com timeouts configuráveis. O protocolo é deliberadamente simples — uma
requisição, uma resposta, conexão fechada — para manter a implementação
auditável.</p>
tes publish <hash></code></strong> — Publica uma tessera na rede. Aceita hashes completos
ou prefixos curtos (ex.: tes publish a1b2</code>), que são resolvidos no banco de
dados local. O daemon lê todos os arquivos da tessera do armazenamento, empacota
em um único buffer MessagePack e entrega ao motor de replicação. Tesseras
pequenas (< 4 MB) são replicadas como um único fragmento; maiores passam por
codificação de apagamento Reed-Solomon. A saída mostra o hash curto e a contagem
de fragmentos:</p>
Published tessera 9f2c4a1b (24 fragments created)
Distribution in progress — use `tes status 9f2c4a1b` to track.
</code></pre>
tes fetch <hash></code></strong> — Busca uma tessera da rede usando o hash de conteúdo
completo. O daemon coleta fragmentos disponíveis localmente, reconstrói os dados
originais via decodificação de apagamento se necessário, desempacota os arquivos
e armazena no CAS (content-addressable store). Retorna o número de memórias e o
tamanho total buscado.</p>
tes status <hash></code></strong> — Exibe a saúde de replicação de uma tessera. A saída
mapeia diretamente o modelo interno de saúde do motor de replicação:</p>
Estado</th> Significado</th></tr></thead>

Local</td> Ainda não publicada — existe apenas na sua máquina</td></tr>
Publishing</td> Fragmentos sendo distribuídos, redundância crítica</td></tr>
Replicated</td> Distribuída, mas abaixo da redundância alvo</td></tr>
Healthy</td> Redundância completa alcançada</td></tr>
</tbody></table>
Listener RPC no daemon</strong> — O daemon agora escuta em um socket Unix (padrão:
$XDG_RUNTIME_DIR/tesseras/daemon.sock</code>) com permissões de diretório adequadas
(0700), limpeza de sockets obsoletos e shutdown gracioso. Cada conexão é tratada
em uma task Tokio — o listener converte o stream assíncrono para I/O síncrono
para a camada de enquadramento, despacha para o handler RPC e escreve a resposta
de volta.</p>
Pack/unpack no tesseras-core</code></strong> — Um módulo pequeno que serializa uma lista
de entradas de arquivo (caminho + dados) em um único buffer MessagePack e
vice-versa. Esta é a ponte entre a estrutura de diretórios da tessera e os blobs
opacos do motor de replicação.</p>
Decisões de arquitetura</h2>

Socket Unix ao invés de TCP</strong>: a comunicação RPC entre CLI e daemon acontece
na mesma máquina. Sockets Unix são mais rápidos, não precisam de alocação de
porta, e as permissões do sistema de arquivos fornecem controle de acesso sem
TLS.</li>
MessagePack ao invés de JSON</strong>: o mesmo formato wire usado em todo o
Tesseras. Compacto, sem schema, e já é uma dependência do workspace. Uma
ida-e-volta típica de publish request/response ocupa menos de 200 bytes.</li>
Cliente síncrono, daemon assíncrono</strong>: o DaemonClient</code> usa I/O bloqueante
porque o CLI não precisa de concorrência — envia uma requisição e espera. O
listener do daemon é assíncrono (Tokio) para tratar múltiplas conexões. A
camada de enquadramento funciona com qualquer impl Read</code>/Write</code>, conectando
ambos os mundos.</li>
Resolução de prefixo no lado do cliente</strong>: publish</code> e status</code> resolvem
prefixos curtos localmente antes de enviar o hash completo ao daemon. Isso
mantém o daemon stateless — ele não precisa acessar o banco de dados do CLI.</li>
Alinhamento do diretório de dados padrão</strong>: o padrão do CLI mudou de
~/.tesseras</code> para ~/.local/share/tesseras</code> (via dirs::data_dir()</code>) para
coincidir com o daemon. Um aviso de migração é exibido quando dados no caminho
antigo são detectados.</li>
</ul>
Próximos passos</h2>

Contagem de peers no DHT</strong>: o comando status</code> atualmente reporta 0 peers —
conectar a contagem real do DHT é o próximo passo</li>
tes show</code></strong>: exibir o conteúdo de uma tessera (memórias, metadados) sem
exportar</li>
Fetch com streaming</strong>: para tesseras grandes, transmitir fragmentos conforme
chegam ao invés de esperar por todos</li>
</ul>


Fase 4: Recuperação de Chaves por Herdeiros com Shamir's Secret Sharing
2026-02-15T00:00:00+00:00
O que acontece com suas memórias quando você morre? Até agora, Tesseras
conseguia preservar conteúdo ao longo de milênios — mas as chaves privadas e
seladas morriam com o dono. A Fase 4 continua com uma solução: Shamir's Secret
Sharing, um esquema criptográfico que permite dividir sua identidade em
fragmentos e distribuí-los para as pessoas em quem você mais confia.</p>
A matemática é elegante: você escolhe um limiar T e um total N. Qualquer T
fragmentos reconstroem o segredo completo; T-1 fragmentos não revelam
absolutamente nada. Isso não é "quase nada" — é informação-teoricamente seguro.
Um atacante com um fragmento a menos que o limiar tem exatamente zero bits de
informação sobre o segredo, independentemente do poder computacional que tenha.</p>
O que foi construído</h2>
Aritmética de corpo finito GF(256)</strong> (tesseras-crypto/src/shamir/gf256.rs</code>) —
Shamir's Secret Sharing requer aritmética em um corpo finito. Implementamos
GF(256) usando o mesmo polinômio irredutível do AES (x^8 + x^4 + x^3 + x + 1),
com tabelas de lookup para logaritmo e exponenciação computadas em tempo de
compilação. Todas as operações são em tempo constante via consulta a tabelas —
sem ramificações baseadas em dados secretos. O módulo inclui o método de Horner
para avaliação de polinômios e interpolação de Lagrange em x=0 para recuperação
do segredo. 233 linhas, exaustivamente testado: todos os 256 elementos para
propriedades de identidade/inverso, comutatividade e associatividade.</p>
ShamirSplitter</strong> (tesseras-crypto/src/shamir/mod.rs</code>) — A API principal de
split/reconstruct. split()</code> recebe uma fatia de bytes do segredo, uma
configuração (limiar T, total N) e a chave pública Ed25519 do dono. Para cada
byte do segredo, constrói um polinômio aleatório de grau T-1 sobre GF(256) com o
byte do segredo como termo constante, e então o avalia em N pontos distintos.
reconstruct()</code> recebe T ou mais fragmentos e recupera o segredo via
interpolação de Lagrange. Ambas as operações incluem validação extensiva:
limites do limiar, consistência de sessão, correspondência de impressão digital
do dono e verificação de checksum BLAKE3.</p>
Formato HeirShare</strong> — Cada fragmento é um artefato autocontido e serializável
com:</p>

Versão do formato (v1) para compatibilidade futura</li>
Índice do fragmento (1..N) e metadados de limiar/total</li>
ID de sessão (8 bytes aleatórios) — impede mistura de fragmentos de sessões
diferentes</li>
Impressão digital do dono (primeiros 8 bytes do hash BLAKE3 da chave pública
Ed25519)</li>
Dados do fragmento (os y-values de Shamir, mesmo comprimento do segredo)</li>
Checksum BLAKE3 sobre todos os campos anteriores</li>
</ul>
Os fragmentos são serializados em dois formatos: MessagePack</strong> (binário
compacto, para uso programático) e texto base64</strong> (legível por humanos, para
impressão e armazenamento físico). O formato texto inclui um cabeçalho com
metadados e delimitadores:</p>
--- TESSERAS HEIR SHARE ---
Format: v1
Owner: a1b2c3d4e5f6a7b8 (fingerprint)
Share: 1 of 3 (threshold: 2)
Session: 9f8e7d6c5b4a3210
Created: 2026-02-15

<dados MessagePack codificados em base64>
--- END HEIR SHARE ---
</code></pre>
Este formato é projetado para ser impresso em papel, armazenado em um cofre
bancário ou gravado em metal. O cabeçalho é informacional — apenas o payload
base64 é analisado durante a reconstrução.</p>
Integração com CLI</strong> (tesseras-cli/src/commands/heir.rs</code>) — Três novos
subcomandos:</p>

tes heir create</code> — divide sua identidade Ed25519 em fragmentos de herdeiros.
Solicita confirmação (sua identidade completa está em jogo), gera arquivos
.bin</code> e .txt</code> para cada fragmento e escreve heir_meta.json</code> no diretório de
identidade.</li>
tes heir reconstruct</code> — carrega arquivos de fragmentos (detecta
automaticamente formato binário vs texto), valida consistência, reconstrói o
segredo, deriva o par de chaves Ed25519 e opcionalmente o instala em
~/.tesseras/identity/</code> (com backup automático da identidade existente).</li>
tes heir info</code> — exibe metadados do fragmento e verifica o checksum sem expor
nenhum material secreto.</li>
</ul>
Formato do blob secreto</strong> — As chaves de identidade são serializadas em um
blob versionado antes da divisão: um byte de versão (0x01), um byte de flags
(0x00 para somente Ed25519), seguido da chave secreta Ed25519 de 32 bytes. Isso
deixa espaço para expansão futura quando as chaves privadas X25519 e ML-KEM-768
forem integradas ao sistema de fragmentos de herdeiros.</p>
Testes</strong> — 20 testes unitários para ShamirSplitter (roundtrip, todas as
combinações de fragmentos, fragmentos insuficientes, dono errado, sessão errada,
limite threshold-1, segredos grandes até o tamanho de chave ML-KEM-768). 7
testes unitários para aritmética GF(256) (propriedades de campo exaustivas). 3
testes baseados em propriedades com proptest (segredos arbitrários até 5000
bytes, configurações T-de-N arbitrárias, verificação de segurança
informação-teórica). Testes de roundtrip de serialização para ambos os formatos
MessagePack e texto base64. 2 testes de integração cobrindo o ciclo de vida
completo de herdeiros: gerar identidade, dividir em fragmentos, serializar,
desserializar, reconstruir, verificar par de chaves e assinar/verificar com
chaves reconstruídas.</p>
Decisões de arquitetura</h2>

GF(256) ao invés de GF(primo)</strong>: usamos GF(256) ao invés de um corpo primo
porque ele mapeia naturalmente para bytes — cada elemento é um único byte,
cada fragmento tem o mesmo comprimento do segredo. Sem aritmética de inteiros
grandes, sem redução modular, sem padding. Esta é a mesma abordagem usada pela
maioria das implementações reais de Shamir, incluindo SSSS e Hashicorp Vault.</li>
Tabelas de lookup em tempo de compilação</strong>: as tabelas LOG e EXP para
GF(256) são computadas em tempo de compilação usando const fn</code>. Isso
significa zero custo de inicialização em tempo de execução e operações em
tempo constante via consulta a tabelas ao invés de loops.</li>
ID de sessão previne mistura entre sessões</strong>: cada chamada a split()</code> gera
um novo ID de sessão aleatório. Se um herdeiro acidentalmente usar fragmentos
de duas sessões diferentes de divisão (por exemplo, antes e depois de uma
rotação de chaves), a reconstrução falha de forma limpa com um erro de
validação ao invés de produzir dados corrompidos.</li>
Checksums BLAKE3 detectam corrupção</strong>: cada fragmento inclui um checksum
BLAKE3 sobre seu conteúdo. Isso captura degradação de bits, erros de
transmissão e truncamento acidental antes de qualquer tentativa de
reconstrução. Um fragmento impresso em papel e escaneado via OCR vai falhar no
checksum se um único caractere estiver errado.</li>
Impressão digital do dono para identificação</strong>: os fragmentos incluem os
primeiros 8 bytes de BLAKE3(chave pública Ed25519) como impressão digital.
Isso permite aos herdeiros verificar a qual identidade um fragmento pertence
sem revelar a chave pública completa. Durante a reconstrução, a impressão
digital é verificada contra a chave recuperada.</li>
Formato duplo para resiliência</strong>: ambos os formatos binário (MessagePack) e
texto (base64) são gerados porque mídias físicas têm modos de falha diferentes
de armazenamento digital. Um pendrive pode falhar; papel sobrevive. Um QR code
pode ficar ilegível; texto base64 pode ser digitado manualmente.</li>
Versionamento do blob</strong>: o segredo é envolvido em um blob versionado
(versão + flags + material de chave) para que versões futuras possam incluir
chaves adicionais (X25519, ML-KEM-768) sem quebrar compatibilidade com
fragmentos existentes.</li>
</ul>
O que vem a seguir</h2>

Fase 4 continuada: Resiliência e Escala</strong> — NAT traversal avançado
(STUN/TURN), ajuste de performance (pool de conexões, cache de fragmentos,
SQLite WAL), auditorias de segurança, integração de nós institucionais,
empacotamento para sistemas operacionais</li>
Fase 5: Exploração e Cultura</strong> — navegador público de tesseras por
era/localização/tema/idioma, curadoria institucional, integração com
genealogia, exportação para mídia física (M-DISC, microfilme, papel livre de
ácido com QR)</li>
</ul>
Com Shamir's Secret Sharing, Tesseras fecha a última lacuna crítica na
preservação a longo prazo. Suas memórias sobrevivem a falhas de infraestrutura
através de erasure coding. Sua privacidade sobrevive a computadores quânticos
através de criptografia híbrida. E agora, sua identidade sobrevive a você —
passada adiante para as pessoas que você escolheu, exigindo a cooperação delas
para desbloquear o que você deixou para trás.</p>


Fase 4: Criptografia e Tesseras Seladas
2026-02-14T16:00:00+00:00
Algumas memórias não são para todos. Um diário privado, uma carta para ser
aberta em 2050, um segredo de família selado até que os netos tenham idade
suficiente. Até agora, toda tessera na rede era aberta. A Fase 4 muda isso:
Tesseras agora criptografa conteúdo privado e selado com um esquema
criptográfico híbrido projetado para resistir tanto a ataques clássicos quanto
quânticos.</p>
O princípio continua o mesmo — criptografar o mínimo possível. Memórias públicas
precisam de disponibilidade, não de sigilo. Mas quando alguém cria uma tessera
privada ou selada, o conteúdo agora é trancado por criptografia AES-256-GCM com
chaves protegidas por um mecanismo híbrido de encapsulamento de chaves
combinando X25519 e ML-KEM-768. Ambos os algoritmos precisam ser quebrados para
acessar o conteúdo.</p>
O que foi construído</h2>
Encriptador AES-256-GCM</strong> (tesseras-crypto/src/encryption.rs</code>) — Criptografia
simétrica de conteúdo com nonces aleatórios de 12 bytes e dados autenticados
associados (AAD). O AAD vincula o texto cifrado ao seu contexto: para tesseras
privadas, o hash do conteúdo é incluído; para tesseras seladas, tanto o hash do
conteúdo quanto o timestamp open_after</code> são vinculados no AAD. Isso significa
que mover texto cifrado entre tesseras com datas de abertura diferentes causa
falha na decriptação — você não consegue enganar o sistema para abrir uma
memória selada antecipadamente trocando o texto cifrado para uma tessera com uma
data de selo anterior.</p>
Mecanismo Híbrido de Encapsulamento de Chaves</strong> (tesseras-crypto/src/kem.rs</code>)
— Troca de chaves usando X25519 (Diffie-Hellman clássico em curva elíptica)
combinado com ML-KEM-768 (o KEM pós-quântico baseado em reticulados padronizado
pelo NIST, anteriormente Kyber). Ambos os segredos compartilhados são combinados
via blake3::derive_key</code> com uma string de contexto fixa ("tesseras hybrid kem
v1") para produzir uma única chave de criptografia de conteúdo de 256 bits. Isso
segue a mesma filosofia "dual desde o início" das assinaturas duplas do projeto
(Ed25519 + ML-DSA): se qualquer algoritmo for quebrado no futuro, o outro ainda
protege o conteúdo.</p>
Envelope de Chave Selada</strong> (tesseras-crypto/src/sealed.rs</code>) — Encapsula uma
chave de criptografia de conteúdo usando o KEM híbrido, para que apenas o dono
da tessera possa recuperá-la. O KEM produz uma chave de transporte, que é XORed
com a chave de conteúdo para produzir uma chave encapsulada armazenada junto ao
texto cifrado do KEM. Ao desselar, o dono decapsula o texto cifrado do KEM para
recuperar a chave de transporte, depois faz XOR novamente para recuperar a chave
de conteúdo.</p>
Publicação de Chave</strong> (tesseras-crypto/src/sealed.rs</code>) — Um artefato assinado
independente para publicar a chave de conteúdo de uma tessera selada após a data
open_after</code> ter passado. O dono assina a chave de conteúdo, o hash da tessera e
o timestamp de publicação com suas chaves duais (Ed25519, com placeholder
ML-DSA). O manifesto permanece imutável — a publicação da chave é um documento
separado. Outros nós verificam a assinatura contra a chave pública do dono antes
de usar a chave publicada para decriptar o conteúdo.</p>
EncryptionContext</strong> (tesseras-core/src/enums.rs</code>) — Um tipo de domínio que
representa o contexto AAD para criptografia. Ele vive em tesseras-core e não em
tesseras-crypto porque é um conceito de domínio (não um detalhe de implementação
criptográfica). O método to_aad_bytes()</code> produz serialização determinística: um
byte de tag (0x00 para Private, 0x01 para Sealed), seguido do hash de conteúdo
e, para Sealed, o timestamp open_after</code> como i64 little-endian.</p>
Validação de domínio</strong> (tesseras-core/src/service.rs</code>) —
TesseraService::create()</code> agora rejeita tesseras Sealed e Private que não
fornecem chaves de criptografia. Esta é uma validação no nível de domínio: a
camada de serviço garante que você não pode criar uma memória selada sem a
maquinaria criptográfica para protegê-la. A mensagem de erro é clara: "missing
encryption keys for visibility sealed until 2050-01-01."</p>
Atualizações de tipos do core</strong> — TesseraIdentity</code> agora inclui um campo
opcional encryption_public: Option<HybridEncryptionPublic></code> contendo tanto as
chaves públicas X25519 quanto ML-KEM-768. KeyAlgorithm</code> ganhou as variantes
X25519</code> e MlKem768</code>. O layout do sistema de arquivos de identidade agora
suporta node.x25519.key</code>/.pub</code> e node.mlkem768.key</code>/.pub</code>.</p>
Testes</strong> — 8 testes unitários para AES-256-GCM (roundtrip, chave errada, texto
cifrado adulterado, AAD errado, falha de decriptação cross-context, nonces
únicos, mais 2 testes baseados em propriedades para payloads arbitrários e
unicidade de nonces). 5 testes unitários para HybridKem (roundtrip, par de
chaves errado, X25519 adulterado, determinismo do KDF, mais 1 teste baseado em
propriedades). 4 testes unitários para SealedKeyEnvelope e KeyPublication. 2
testes de integração cobrindo o ciclo de vida completo de tesseras seladas e
privadas: gerar chaves, criar chave de conteúdo, criptografar, selar, desselar,
decriptar, publicar chave e verificar — o ciclo completo.</p>
Decisões de arquitetura</h2>

KEM híbrido desde o início</strong>: X25519 + ML-KEM-768 segue a mesma filosofia
das assinaturas duplas. Não sabemos quais suposições criptográficas se
manterão ao longo dos milênios, então combinamos algoritmos clássicos e
pós-quânticos. O custo é ~1,2 KB de material de chave adicional por identidade
— trivial comparado às fotos e vídeos em uma tessera.</li>
BLAKE3 para KDF</strong>: ao invés de adicionar hkdf</code> + sha2</code> como novas
dependências, usamos blake3::derive_key</code> com uma string de contexto fixa. O
modo de derivação de chaves do BLAKE3 é especificamente projetado para este
caso de uso, e o projeto já depende do BLAKE3 para hashing de conteúdo.</li>
Manifestos imutáveis</strong>: quando a data open_after</code> de uma tessera selada
passa, a chave de conteúdo é publicada como um artefato assinado separado
(KeyPublication</code>), não modificando o manifesto. Isso preserva a natureza
append-only e endereçada por conteúdo das tesseras. O manifesto foi assinado
no momento da criação e nunca muda.</li>
Vinculação AAD previne troca de texto cifrado</strong>: o EncryptionContext</code>
vincula tanto o hash de conteúdo quanto (para tesseras seladas) o timestamp
open_after</code> nos dados autenticados do AES-GCM. Um atacante que copie conteúdo
criptografado de uma tessera "selada até 2050" para uma tessera "selada até
2025" vai descobrir que a decriptação falha — o AAD não corresponde mais.</li>
Encapsulamento de chave por XOR</strong>: o envelope de chave selada usa um XOR
simples da chave de conteúdo com a chave de transporte derivada do KEM, ao
invés de uma camada adicional de AES-GCM. Como a chave de transporte é um
valor aleatório fresco do KEM e é usada exatamente uma vez, o XOR é
informação-teoricamente seguro para este caso de uso específico e evita
complexidade desnecessária.</li>
Validação de domínio, não validação de storage</strong>: a verificação de "chaves
de criptografia ausentes" vive em TesseraService::create()</code>, não na camada de
storage. Isso segue o padrão de arquitetura hexagonal: regras de domínio são
aplicadas na fronteira de serviço, não espalhadas pelos adaptadores.</li>
</ul>
O que vem a seguir</h2>

Fase 4 continuada: Resiliência e Escala</strong> — Shamir's Secret Sharing para
distribuição de chaves de herdeiros, NAT traversal avançado (STUN/TURN),
ajuste de performance, auditorias de segurança, empacotamento para sistemas
operacionais</li>
Fase 5: Exploração e Cultura</strong> — Navegador público de tesseras por
era/localização/tema/idioma, curadoria institucional, integração com
genealogia, exportação para mídia física (M-DISC, microfilme, papel livre de
ácido com QR)</li>
</ul>
Tesseras seladas fazem do Tesseras uma verdadeira cápsula do tempo. Um pai agora
pode gravar uma mensagem para o neto que ainda não nasceu, selá-la até 2060 e
saber que o envelope criptográfico vai resistir — mesmo que os computadores
quânticos do futuro tentem abri-lo antes da hora.</p>


Fase 3: Memórias nas Suas Mãos
2026-02-14T14:00:00+00:00
As pessoas agora podem segurar suas memórias nas próprias mãos. A Fase 3 entrega
o que as fases anteriores construíram: um app mobile onde alguém baixa o
Tesseras, cria uma identidade, tira uma foto, e aquela memória entra na rede de
preservação. Sem contas na nuvem, sem assinaturas, sem nenhuma empresa entre
você e suas memórias.</p>
O que foi construído</h2>
tesseras-embedded</strong> — Um nó P2P completo que roda dentro de um app mobile. A
struct EmbeddedNode</code> é dona de um runtime Tokio, banco SQLite, transporte QUIC,
engine Kademlia DHT, serviço de replicação e serviço de tessera — a mesma stack
do daemon desktop, compilada como biblioteca compartilhada. Um padrão singleton
global (Mutex<Option<EmbeddedNode>></code>) garante um único nó por ciclo de vida do
app. Ao iniciar, ele abre o banco de dados, executa migrações, carrega ou gera
uma identidade Ed25519 com proof-of-work para o node ID, faz bind QUIC numa
porta efêmera, conecta DHT e replicação, e inicia o loop de reparo. Ao parar,
envia um sinal de shutdown e drena graciosamente.</p>
Onze funções FFI são expostas para Dart via flutter_rust_bridge: ciclo de vida
(node_start</code>, node_stop</code>, node_is_running</code>), identidade (create_identity</code>,
get_identity</code>), memórias (create_memory</code>, get_timeline</code>, get_memory</code>) e
status da rede (get_network_stats</code>, get_replication_status</code>). Todos os tipos
que cruzam a fronteira FFI são structs planas com apenas String</code>,
Option<String></code>, Vec<String></code> e primitivos — sem trait objects, sem generics,
sem lifetimes.</p>
Quatro módulos adaptadores fazem a ponte entre as ports do core e as
implementações concretas: Blake3HasherAdapter</code>,
Ed25519SignerAdapter</code>/Ed25519VerifierAdapter</code> para criptografia,
DhtPortAdapter</code> para operações DHT, e ReplicationHandlerAdapter</code> para RPCs de
fragmentos e atestação recebidos.</p>
A feature flag bundled-sqlite</code> compila o SQLite a partir do código-fonte,
necessário para Android e iOS onde a biblioteca do sistema pode não estar
disponível. A configuração do Cargokit passa essa flag automaticamente em builds
de debug e release.</p>
App Flutter</strong> — Uma aplicação Material Design 3 com gerenciamento de estado
Riverpod, direcionada para Android, iOS, Linux, macOS e Windows a partir de uma
única base de código.</p>
O fluxo de onboarding</em> são três telas: uma tela de boas-vindas explicando o
projeto em uma frase ("Preserve suas memórias através dos milênios. Sem nuvem.
Sem empresa."), uma tela de criação de identidade que dispara a geração do par
de chaves Ed25519 em Rust, e uma tela de confirmação mostrando o nome do usuário
e a identidade criptográfica.</p>
A tela de timeline</em> exibe memórias em ordem cronológica reversa com previews de
imagem, texto de contexto e chips para tipo de memória e visibilidade.
Pull-to-refresh recarrega a partir do nó Rust. Um floating action button abre a
tela de criação de memória</em>, que suporta seleção de foto da galeria ou câmera
via image_picker</code>, texto de contexto opcional, dropdowns de tipo de memória e
visibilidade, e tags separadas por vírgula. Criar uma memória chama o FFI Rust
sincronamente, depois retorna à timeline.</p>
A tela de rede</em> mostra dois cards: status do nó (contagem de peers, tamanho da
DHT, estado de bootstrap, uptime) e saúde da replicação (total de fragmentos,
fragmentos saudáveis, fragmentos em reparo, fator de replicação). A tela de
configurações</em> exibe a identidade do usuário — nome, node ID truncado, chave
pública truncada e data de criação.</p>
Três providers Riverpod gerenciam o estado: nodeProvider</code> inicia o nó embarcado
ao abrir o app usando o diretório de documentos e para ao fazer dispose;
identityProvider</code> carrega o perfil existente ou cria um novo;
timelineProvider</code> busca a lista de memórias com paginação.</p>
Testes</strong> — 9 testes unitários Rust em tesseras-embedded cobrindo ciclo de vida
do nó (start/stop sem panic), persistência de identidade entre reinícios, ciclos
de reinício sem corrupção do SQLite, streaming de eventos de rede, recuperação
de estatísticas, criação de memória e recuperação da timeline, e busca de
memória individual por hash. 2 testes Flutter: um teste de integração
verificando inicialização do Rust e startup do app, e um smoke test de widget.</p>
Decisões de arquitetura</h2>

Nó embarcado, não cliente-servidor</strong>: o celular roda a stack P2P completa,
não um thin client conversando com um daemon remoto. Isso significa que
memórias são preservadas mesmo sem internet. Usuários com um Raspberry Pi ou
VPS podem opcionalmente conectar o app ao seu daemon via GraphQL para maior
disponibilidade, mas não é obrigatório.</li>
FFI síncrono</strong>: todas as funções flutter_rust_bridge são marcadas como
#[frb(sync)]</code> e bloqueiam no runtime Tokio interno. Isso simplifica o lado
Dart (sem complexidade de bridge assíncrono) enquanto o lado Rust lida com
concorrência internamente. A UI thread do Flutter permanece responsiva porque
o Riverpod envolve as chamadas em providers assíncronos.</li>
Singleton global</strong>: um global Mutex<Option<EmbeddedNode>></code> garante que o
ciclo de vida do nó seja previsível — um start, um stop, sem race conditions.
Plataformas mobile matam processos agressivamente, então simplicidade no
gerenciamento de ciclo de vida é uma feature.</li>
Tipos FFI planos</strong>: nenhuma abstração Rust vaza pela fronteira FFI. Todo
tipo é uma struct plana com strings e números. Isso torna os bindings Dart
auto-gerados confiáveis e fáceis de debugar.</li>
Onboarding de três telas</strong>: a criação de identidade é o único passo
obrigatório. Sem email, sem senha, sem registro em servidor. O app gera uma
identidade criptográfica localmente e está pronto para uso.</li>
</ul>
O que vem a seguir</h2>

Fase 4: Resiliência e Escala</strong> — NAT traversal avançado (STUN/TURN),
Shamir's Secret Sharing para herdeiros, tesseras seladas com criptografia
temporal, ajuste de performance, auditorias de segurança, empacotamento para
Alpine/Arch/Debian/FreeBSD/OpenBSD</li>
Fase 5: Exploração e Cultura</strong> — Navegador público de tesseras por
era/localização/tema/idioma, curadoria institucional, integração com
genealogia, exportação para mídia física (M-DISC, microfilme, papel livre de
ácido com QR)</li>
</ul>
A infraestrutura está completa. A rede existe, a replicação funciona, e agora
qualquer pessoa com um celular pode participar. O que resta é fortalecer o que
temos e abrir para o mundo.</p>


Reed-Solomon: Como o Tesseras Sobrevive à Perda de Dados
2026-02-14T14:00:00+00:00
Seu disco rígido vai morrer. Seu provedor de nuvem vai pivotar. O array RAID no
seu armário vai sobreviver ao controlador, mas não ao dono. Se uma memória está
armazenada em exatamente um lugar, ela tem exatamente uma forma de se perder
para sempre.</p>
Tesseras é uma rede que mantém memórias humanas vivas através de ajuda mútua. O
mecanismo central de sobrevivência é a codificação de apagamento
Reed-Solomon</strong> — uma técnica emprestada da comunicação espacial profunda que nos
permite reconstruir dados mesmo quando pedaços desaparecem.</p>
O que é Reed-Solomon?</h2>
Reed-Solomon é uma família de códigos corretores de erros inventada por Irving
Reed e Gustave Solomon em 1960. O caso de uso original era corrigir erros em
dados transmitidos por canais ruidosos — pense na Voyager enviando fotos de
Júpiter, ou num CD tocando apesar de arranhões.</p>
A ideia-chave: se você adicionar redundância cuidadosamente calculada aos seus
dados antes</em> que algo dê errado, você pode recuperar o original mesmo depois de
perder alguns pedaços.</p>
Eis a intuição. Suponha que você tenha um polinômio de grau 2 — uma parábola.
Você precisa de 3 pontos para defini-lo de forma única. Mas se você avaliá-lo em
5 pontos, pode perder quaisquer 2 desses 5 e ainda reconstruir o polinômio a
partir dos 3 restantes. Reed-Solomon generaliza essa ideia para trabalhar sobre
corpos finitos (corpos de Galois), onde o "polinômio" são seus dados e os
"pontos de avaliação" são seus fragmentos.</p>
Em termos concretos:</p>

Divida</strong> seus dados em k</em> shards de dados</li>
Calcule</strong> m</em> shards de paridade a partir dos shards de dados</li>
Distribua</strong> todos os k + m</em> shards em diferentes locais</li>
Reconstrua</strong> os dados originais a partir de quaisquer k</em> dos k + m</em>
shards</li>
</ol>
Você pode perder até m</em> shards — quaisquer m</em>, de dados ou paridade, em
qualquer combinação — e ainda recuperar tudo.</p>
Por que não simplesmente fazer cópias?</h2>
A abordagem ingênua para redundância é a replicação: faça 3 cópias, armazene-as
em 3 lugares. Isso dá tolerância a 2 falhas ao custo de 3x o seu armazenamento.</p>
Reed-Solomon é dramaticamente mais eficiente:</p>
Estratégia</th> Overhead de armazenamento</th> Falhas toleradas</th></tr></thead>

Replicação 3x</td> 200%</td> 2 de 3</td></tr>
Reed-Solomon (16,8)</td> 50%</td> 8 de 24</td></tr>
Reed-Solomon (48,24)</td> 50%</td> 24 de 72</td></tr>
</tbody></table>
Com 16 shards de dados e 8 de paridade, você usa 50% de armazenamento extra mas
pode sobreviver à perda de um terço de todos os fragmentos. Para alcançar a
mesma tolerância a falhas só com replicação, você precisaria de 3x o
armazenamento.</p>
Para uma rede que visa preservar memórias ao longo de décadas e séculos, essa
eficiência não é um luxo — é a diferença entre um sistema viável e um que se
afoga no próprio overhead.</p>
Como o Tesseras usa Reed-Solomon</h2>
Nem todos os dados merecem o mesmo tratamento. Uma memória de texto de 500 bytes
e um vídeo de 100 MB têm necessidades de redundância muito diferentes. O
Tesseras usa uma estratégia de fragmentação em três camadas:</p>
Small (< 4 MB)</strong> — Replicação do arquivo inteiro para 7 pares. Para tesseras
pequenas, o overhead da codificação de apagamento (tempo de codificação,
gerenciamento de fragmentos, lógica de reconstrução) supera seus benefícios.
Cópias simples são mais rápidas e mais simples.</p>
Medium (4–256 MB)</strong> — 16 shards de dados + 8 de paridade = 24 fragmentos no
total. Cada fragmento tem aproximadamente 1/16 do tamanho original. Quaisquer 16
dos 24 fragmentos reconstroem o original. Distribuídos entre 7 pares.</p>
Large (≥ 256 MB)</strong> — 48 shards de dados + 24 de paridade = 72 fragmentos no
total. Maior contagem de shards significa fragmentos individuais menores (mais
fáceis de transferir e armazenar) e maior tolerância absoluta a falhas. Também
distribuídos entre 7 pares.</p>
A implementação usa o crate reed-solomon-erasure</code> operando sobre GF(2⁸) — o
mesmo corpo de Galois usado em códigos QR e CDs. Cada fragmento carrega um
checksum BLAKE3 para que a corrupção seja detectada imediatamente, não propagada
silenciosamente.</p>
Tessera (álbum de fotos de 120 MB)
    ↓ codificar
16 shards de dados (7,5 MB cada) + 8 shards de paridade (7,5 MB cada)
    ↓ distribuir
24 fragmentos entre 7 pares (diversidade de sub-rede)
    ↓ quaisquer 16 fragmentos
Tessera original recuperada
</code></pre>
Os desafios</h2>
Reed-Solomon resolve o problema matemático da redundância. Os desafios de
engenharia estão em tudo ao redor.</p>
Rastreamento de fragmentos</h3>
Cada fragmento precisa ser localizável. O Tesseras usa uma DHT Kademlia para
descoberta de pares e mapeamento de fragmentos para pares. Quando um nó fica
offline, seus fragmentos precisam ser recriados e distribuídos para novos pares.
Isso significa rastrear quais fragmentos existem, onde estão e se ainda estão
intactos — numa rede sem autoridade central.</p>
Corrupção silenciosa</h3>
Um fragmento que retorna dados errados é pior que um ausente — pelo menos um
fragmento ausente é honestamente ausente. O Tesseras aborda isso com
verificações de saúde baseadas em atestação: o loop de reparo periodicamente
pede aos detentores de fragmentos que provem posse retornando checksums BLAKE3.
Se um checksum não bater, o fragmento é tratado como perdido.</p>
Falhas correlacionadas</h3>
Se todos os 24 fragmentos de uma tessera caírem em máquinas no mesmo datacenter,
uma única queda de energia os elimina todos. A matemática do Reed-Solomon assume
falhas independentes. O Tesseras impõe diversidade de sub-rede</strong> durante a
distribuição: no máximo 2 fragmentos por sub-rede /24 IPv4 (ou prefixo /48
IPv6). Isso espalha fragmentos por diferentes infraestruturas físicas.</p>
Velocidade de reparo vs. carga na rede</h3>
Quando um par fica offline, o relógio começa a contar. Fragmentos perdidos
precisam ser recriados antes que mais falhas se acumulem. Mas reparo agressivo
inunda a rede. O Tesseras equilibra isso com um loop de reparo configurável
(padrão: a cada 24 horas com 2 horas de jitter) e limites de transferências
simultâneas (padrão: 4 transferências simultâneas). O jitter previne tempestades
de reparo onde cada nó verifica seus fragmentos no mesmo momento.</p>
Gerenciamento de chaves a longo prazo</h3>
Reed-Solomon protege contra perda de dados, não contra perda de acesso. Se uma
tessera é criptografada (visibilidade privada ou selada), você precisa da chave
de descriptografia para tornar os dados recuperados úteis. O Tesseras separa
essas preocupações: codificação de apagamento cuida da disponibilidade, enquanto
o Compartilhamento de Segredo de Shamir (uma fase futura) cuidará da
distribuição de chaves entre herdeiros. A filosofia de design do projeto —
criptografar o mínimo possível — mantém o problema de gerenciamento de chaves
pequeno.</p>
Limitações do corpo de Galois</h3>
O corpo GF(2⁸) limita o número total de shards a 255 (dados + paridade
combinados). Para o Tesseras, isso não é uma restrição prática — mesmo a camada
Large usa apenas 72 shards. Mas significa que arquivos extremamente grandes com
milhares de fragmentos exigiriam um corpo diferente ou um esquema de codificação
em camadas.</p>
Compatibilidade evolutiva do codec</h3>
Uma tessera codificada hoje precisa ser decodificável em 50 anos. Reed-Solomon
sobre GF(2⁸) é um dos algoritmos mais amplamente implementados na computação —
está em todo leitor de CD, em todo scanner de código QR, em toda sonda espacial.
Essa ubiquidade é em si uma estratégia de sobrevivência. O algoritmo não será
esquecido porque metade da infraestrutura do mundo depende dele.</p>
O quadro geral</h2>
Reed-Solomon é uma peça de um quebra-cabeça maior. Ele trabalha em conjunto com:</p>

DHT Kademlia</strong> para encontrar pares e rotear fragmentos</li>
Checksums BLAKE3</strong> para verificação de integridade</li>
Reciprocidade bilateral</strong> para troca justa de armazenamento (sem blockchain)</li>
Diversidade de sub-rede</strong> para independência de falhas</li>
Reparo automático</strong> para manter a redundância ao longo do tempo</li>
</ul>
Nenhuma técnica isolada faz memórias sobreviverem. Reed-Solomon garante que
dados podem</em> ser recuperados. A DHT garante que fragmentos podem ser
encontrados</em>. A reciprocidade garante que pares querem ajudar</em>. O reparo
garante que nada disso se degrade com o tempo.</p>
Uma tessera é uma aposta de que a soma desses mecanismos, rodando em muitas
máquinas independentes operadas por muitas pessoas independentes, é mais durável
que qualquer instituição isolada. Reed-Solomon é a fundação matemática dessa
aposta.</p>


Fase 2: Memórias Sobrevivem
2026-02-14T12:00:00+00:00
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.</p>
O que foi construído</h2>
tesseras-core</strong> (atualizado) — Novos tipos de domínio de replicação:
FragmentPlan</code> (seleciona a camada de fragmentação baseada no tamanho da
tessera), FragmentId</code> (hash da tessera + índice + contagem de shards +
checksum), FragmentEnvelope</code> (fragmento com seus metadados para transporte na
rede), FragmentationTier</code> (Small/Medium/Large), Attestation</code> (prova de que um
nó possui um fragmento em um dado momento) e ReplicateAck</code> (confirmação de
recebimento de fragmento). Três novas traits de porta definem os limites
hexagonais: DhtPort</code> (encontrar pares, replicar fragmentos, solicitar
atestações, ping), FragmentStore</code> (armazenar/ler/deletar/listar/verificar
fragmentos) e ReciprocityLedger</code> (registrar trocas de armazenamento, consultar
saldos, encontrar melhores pares). O tamanho máximo de uma tessera é 1 GB.</p>
tesseras-crypto</strong> (atualizado) — O ReedSolomonCoder</code> 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.</p>
tesseras-storage</strong> (atualizado) — Dois novos adaptadores:</p>

FsFragmentStore</code> — armazena dados de fragmentos como arquivos em disco
({raiz}/{hash_tessera}/{indice:03}.shard</code>) 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.</li>
SqliteReciprocityLedger</code> — 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</code> é uma coluna gerada
(bytes_they_store_for_us - bytes_stored_for_them</code>). UPSERT garante incremento
atômico dos contadores.</li>
</ul>
Nova migração (002_replication.sql</code>) adiciona tabelas para fragmentos, planos
de fragmentação, detentores, mapeamentos detentor-fragmento e saldos de
reciprocidade.</p>
tesseras-dht</strong> (atualizado) — Quatro novas variantes de mensagem: Replicate</code>
(enviar um envelope de fragmento), ReplicateAck</code> (confirmar recebimento),
AttestRequest</code> (pedir a um nó que prove que possui os fragmentos de uma
tessera) e AttestResponse</code> (retornar atestação com checksums e timestamp). O
engine trata essas mensagens em seu loop de despacho.</p>
tesseras-replication</strong> — O novo crate, com cinco módulos:</p>


Codificação de fragmentos</em> (fragment.rs</code>): encode_tessera()</code> 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:</p>

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

Distribuição</em> (distributor.rs</code>): 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.</p>
</li>

Serviço</em> (service.rs</code>): ReplicationService</code> é o orquestrador.
replicate_tessera()</code> codifica os dados, encontra os pares mais próximos via
DHT, aplica diversidade de sub-rede e distribui fragmentos em round-robin.
receive_fragment()</code> 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()</code> lista os fragmentos locais e calcula seus
checksums como prova de posse.</p>
</li>

Reparo</em> (repair.rs</code>): check_tessera_health()</code> 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</code>,
NeedsReplication { deficit }</code> ou CorruptLocal { fragment_index }</code>. O loop de
reparo roda a cada 24 horas (com 2 horas de jitter) via tokio::select!</code> com
integração de desligamento.</p>
</li>

Configuração</em> (config.rs</code>): ReplicationConfig</code> 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).</p>
</li>
</ul>
tesd</strong> (atualizado) — O daemon agora abre um banco de dados SQLite
(db/tesseras.db</code>), executa migrações, cria instâncias de FsFragmentStore</code>,
SqliteReciprocityLedger</code> e FsBlobStore</code>, envolve o engine DHT em um
DhtPortAdapter</code>, constrói um ReplicationService</code> e lança o loop de reparo como
tarefa em segundo plano com desligamento gracioso.</p>
Testes</strong> — 193 testes em todo o workspace:</p>

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)</li>
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)</li>
Testes usam SQLite em memória + diretório temporário para fragmentos com mocks
mockall para DHT e BlobStore</li>
Zero avisos do clippy, formatação limpa</li>
</ul>
Decisões de arquitetura</h2>

Fragmentação em três camadas</strong>: 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.</li>
Distribuição por push do dono</strong>: 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.</li>
Reciprocidade bilateral sem consenso</strong>: 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.</li>
Diversidade de sub-rede</strong>: 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.</li>
Verificações de saúde por atestação primeiro</strong>: 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.</li>
</ul>
O que vem a seguir</h2>

Fase 3: API e Apps</strong> — App Flutter mobile/desktop via flutter_rust_bridge,
API GraphQL (async-graphql), nó WASM no navegador</li>
Fase 4: Resiliência e Escala</strong> — 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</li>
Fase 5: Exploração e Cultura</strong> — navegador público de tesseras, curadoria
institucional, integração genealógica, exportação para mídia física</li>
</ul>
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.</p>


Fase 1: Nós Se Encontram
2026-02-14T11:00:00+00:00
Tesseras não é mais uma ferramenta apenas local. A Fase 1 entrega a camada de
rede: nós se descobrem através de uma DHT Kademlia, comunicam-se sobre QUIC e
publicam ponteiros de tesseras que qualquer par na rede pode encontrar. Uma
tessera criada no nó A agora pode ser encontrada a partir do nó C.</p>
O que foi construído</h2>
tesseras-core</strong> (atualizado) — Novos tipos de domínio de rede:
TesseraPointer</code> (referência leve aos detentores de uma tessera e localização
dos fragmentos), NodeIdentity</code> (ID do nó + chave pública + nonce de prova de
trabalho), NodeInfo</code> (identidade + endereço + capacidades) e Capabilities</code>
(bitflags do que um nó suporta: DHT, armazenamento, relay, replicação).</p>
tesseras-net</strong> — A camada de transporte, construída sobre QUIC via quinn. A
trait Transport</code> define a porta: send</code>, recv</code>, disconnect</code>, local_addr</code>.
Dois adaptadores a implementam:</p>

QuinnTransport</code> — QUIC real com TLS auto-assinado, negociação ALPN
(tesseras/1</code>), pool de conexões via DashMap e um loop de aceitação em
background que trata streams recebidas.</li>
MemTransport</code> + SimNetwork</code> — canais em memória para testes determinísticos
sem I/O de rede. Cada teste de integração no crate DHT roda contra este
adaptador.</li>
</ul>
O protocolo de fio usa MessagePack com prefixo de comprimento: um cabeçalho de 4
bytes big-endian seguido de um payload rmp-serde. WireMessage</code> carrega um byte
de versão, ID de requisição e um corpo que pode ser requisição, resposta ou erro
de protocolo. Tamanho máximo de mensagem é 64 KiB.</p>
tesseras-dht</strong> — Uma implementação completa de Kademlia:</p>

Tabela de roteamento</em>: 160 k-buckets com k=20. Evicção do menos recentemente
visto, mover-para-trás ao atualizar, verificação por ping antes de substituir
a entrada mais antiga de um bucket cheio.</li>
Distância XOR</em>: métrica XOR de 160 bits com indexação de bucket pelo bit mais
significativo diferente.</li>
Prova de trabalho</em>: nós iteram um nonce até que
BLAKE3(pubkey || nonce)[..20]</code> tenha 8 bits zero iniciais (~256 tentativas de
hash em média). Barato o suficiente para qualquer dispositivo, caro o
suficiente para tornar ataques Sybil impraticáveis em escala.</li>
Mensagens de protocolo</em>: Ping/Pong, FindNode/FindNodeResponse,
FindValue/FindValueResult, Store — todos serializados com MessagePack via
serde.</li>
Armazenamento de ponteiros</em>: armazenamento em memória limitado com TTL
configurável (24 horas padrão) e máximo de entradas (10.000 padrão). Quando
cheio, remove ponteiros mais distantes do ID do nó local, seguindo o modelo de
responsabilidade baseado em distância do Kademlia.</li>
DhtEngine</em>: o orquestrador principal. Trata RPCs recebidos, executa buscas
iterativas (paralelismo alpha=3), bootstrap, publicação e busca. O método
run()</code> dirige um loop tokio::select!</code> com timers de manutenção: refresh da
tabela de roteamento a cada 60 segundos, expiração de ponteiros a cada 5
minutos.</li>
</ul>
tesd</strong> — Um binário de nó completo. Analisa argumentos de CLI (endereço de
bind, pares de bootstrap, diretório de dados), gera uma identidade de nó válida
por PoW, abre um endpoint QUIC, faz bootstrap na rede e roda o motor DHT.
Desligamento gracioso com Ctrl+C via tratamento de sinais do tokio.</p>
Infraestrutura</strong> — Configuração OpenTofu para dois nós bootstrap no Hetzner
Cloud (instâncias cx22 em Falkenstein, Alemanha e Helsinki, Finlândia). Script
de provisionamento cloud-init cria um usuário dedicado tesseras</code>, escreve um
arquivo de configuração e configura um serviço systemd. Regras de firewall abrem
UDP 4433 (QUIC) e restringem métricas a acesso interno.</p>
Testes</strong> — 139 testes em todo o workspace:</p>

47 testes unitários em tesseras-dht (tabela de roteamento, distância, PoW,
armazenamento de ponteiros, serialização de mensagens, RPCs do engine)</li>
5 testes de integração multi-nó (bootstrap de 3 nós, convergência de lookup
com 10 nós, publicar-e-encontrar, detecção de partida de nó, rejeição de PoW)</li>
14 testes em tesseras-net (roundtrips de codec, send/recv de transporte,
backpressure, disconnect)</li>
Testes de fumaça com Docker Compose usando 3 nós containerizados comunicando
sobre QUIC real</li>
Zero avisos do clippy, formatação limpa</li>
</ul>
Decisões de arquitetura</h2>

Transport como porta</strong>: a trait Transport</code> é a única interface entre o
motor DHT e a rede. Trocar QUIC por qualquer outro protocolo significa
implementar quatro métodos. Todos os testes de DHT usam o adaptador em
memória, tornando-os rápidos e determinísticos.</li>
Um stream por RPC</strong>: cada par requisição-resposta DHT usa um stream
bidirecional QUIC novo. Sem complexidade de multiplexação, sem bloqueio
head-of-line entre operações independentes. O QUIC trata a multiplexação no
nível da conexão.</li>
MessagePack em vez de Protobuf</strong>: codificação binária compacta sem geração
de código ou arquivos de esquema. Integração com serde significa que adicionar
um campo a uma mensagem é uma mudança de uma linha. Trade-off: sem garantias
de evolução de esquema embutidas, mas neste estágio velocidade importa mais.</li>
PoW em vez de stake ou reputação</strong>: uma identidade de nó custa ~256 hashes
BLAKE3. Isso roda em menos de um segundo em qualquer hardware, incluindo um
Raspberry Pi, mas gerar milhares de identidades para um ataque Sybil se torna
caro. Sem tokens, sem blockchain, sem dependências externas.</li>
Busca iterativa com atualização da tabela de roteamento</strong>: nós descobertos
são adicionados à tabela de roteamento conforme encontrados durante buscas
iterativas, seguindo o comportamento padrão do Kademlia. Isso garante que a
tabela de roteamento melhore organicamente conforme os nós interagem.</li>
</ul>
O que vem a seguir</h2>

Fase 2: Replicação</strong> — Codificação de apagamento Reed-Solomon pela rede,
distribuição de fragmentos, loops de reparo automáticos, livro-razão de
reciprocidade bilateral (sem blockchain, sem tokens)</li>
Fase 3: API e Apps</strong> — App Flutter mobile/desktop via flutter_rust_bridge,
API GraphQL (async-graphql), nó WASM no navegador</li>
Fase 4: Resiliência e Escala</strong> — 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</li>
Fase 5: Exploração e Cultura</strong> — navegador público de tesseras, curadoria
institucional, integração genealógica, exportação para mídia física</li>
</ul>
Os nós conseguem se encontrar. Em seguida, aprendem a manter vivas as memórias
uns dos outros.</p>


Fase 0: Fundação Construída
2026-02-14T10:00:00+00:00
O primeiro marco do projeto Tesseras está completo. A Fase 0 estabelece a
fundação sobre a qual cada componente futuro será construído: tipos de domínio,
criptografia, armazenamento e uma interface de linha de comando funcional.</p>
O que foi construído</h2>
tesseras-core</strong> — A camada de domínio define o formato tessera: ContentHash</code>
(BLAKE3, 32 bytes), NodeId</code> (Kademlia, 20 bytes), tipos de memória (Moment,
Reflection, Daily, Relation, Object), modos de visibilidade (Private, Circle,
Public, PublicAfterDeath, Sealed) e um formato de manifesto em texto plano que
pode ser interpretado por qualquer linguagem de programação pelos próximos mil
anos. A camada de serviço (TesseraService</code>) gerencia operações de criação,
verificação, exportação e listagem através de port traits, seguindo arquitetura
hexagonal.</p>
tesseras-crypto</strong> — Geração de chaves Ed25519, assinatura e verificação. Um
framework de assinatura dual (Ed25519 + placeholder ML-DSA) pronto para migração
pós-quântica. Hashing de conteúdo com BLAKE3. Codificação de apagamento
Reed-Solomon atrás de uma feature flag para futura replicação.</p>
tesseras-storage</strong> — Índice SQLite via rusqlite com migrações em SQL puro.
Blob store no sistema de arquivos com layout endereçável por conteúdo
(blobs/<tessera_hash>/<memory_hash>/<filename></code>). Persistência de chaves de
identidade em disco.</p>
tesseras-cli</strong> — Um binário tesseras</code> funcional com cinco comandos:</p>

init</code> — gera identidade Ed25519, cria banco de dados SQLite</li>
create <dir></code> — varre um diretório por arquivos de mídia, cria uma tessera
assinada</li>
verify <hash></code> — verifica assinatura e integridade dos arquivos</li>
export <hash> <dest></code> — escreve um diretório tessera autocontido</li>
list</code> — mostra uma tabela das tesseras armazenadas</li>
</ul>
Testes</strong> — 67+ testes em todo o workspace: testes unitários em cada módulo,
testes baseados em propriedades (proptest) para roundtrips hex e serialização de
manifesto, testes de integração cobrindo o ciclo completo de
criação-verificação-exportação incluindo detecção de arquivos adulterados e
assinaturas inválidas. Zero avisos do clippy.</p>
Decisões de arquitetura</h2>

Arquitetura hexagonal</strong>: operações criptográficas são injetadas via trait
objects (Box<dyn Hasher></code>, Box<dyn ManifestSigner></code>,
Box<dyn ManifestVerifier></code>), mantendo o crate core livre de dependências
criptográficas concretas.</li>
Feature flags</strong>: a feature service</code> no tesseras-core controla a camada de
aplicação assíncrona. As features classical</code> e erasure</code> no tesseras-crypto
controlam quais algoritmos são compilados.</li>
Manifesto em texto plano</strong>: interpretável sem qualquer biblioteca de formato
binário, com prefixos de hash explícitos blake3:</code> e layout legível por
humanos.</li>
</ul>
O que vem a seguir</h2>
A Fase 0 é a fundação local. O caminho adiante:</p>

Fase 1: Rede</strong> — Transporte QUIC (quinn), DHT Kademlia para descoberta de
pares, travessia de NAT</li>
Fase 2: Replicação</strong> — Codificação de apagamento Reed-Solomon pela rede,
loops de reparo, reciprocidade bilateral (sem blockchain, sem tokens)</li>
Fase 3: Clientes</strong> — App Flutter mobile/desktop via flutter_rust_bridge, API
GraphQL, nó WASM no navegador</li>
Fase 4: Endurecimento</strong> — Assinaturas pós-quânticas ML-DSA, empacotamento
para Alpine/Arch/Debian/FreeBSD/OpenBSD, CI no SourceHut</li>
</ul>
O formato tessera é estável. Tudo construído a partir daqui se conecta e estende
o que existe hoje.</p>


Olá, Mundo
2026-02-13T00:00:00+00:00
Hoje anunciamos o projeto Tesseras: uma rede peer-to-peer para preservar
memórias humanas através dos milênios.</p>
Tesseras é construído sobre uma ideia simples — suas fotos, gravações e escritos
merecem sobreviver a qualquer empresa, plataforma ou formato de arquivo. Cada
pessoa cria uma tessera, uma cápsula do tempo autocontida que a rede mantém viva
através de ajuda mútua e redundância.</p>
O projeto está em seu estágio mais inicial. Estamos construindo a fundação:
ferramentas para criar, verificar e exportar tesseras offline. A camada de rede,
replicação e aplicativos virão em seguida.</p>
Se essa missão ressoa com você,
entre na lista de discussão</a> ou navegue pelo
código-fonte</a>.</p>
Tesseras

Empacotando o Tesseras para Debian

Empacotando o Tesseras para Arch Linux

Fase 4: Deduplicacao de Armazenamento

Fase 4: Onboarding de Nos Institucionais

Fase 4: Tuning de Performance

Fase 4: Verificar Sem Instalar Nada

Fase 4: Furando NATs

CLI Encontra a Rede: Comandos Publish, Fetch e Status

Fase 4: Recuperação de Chaves por Herdeiros com Shamir's Secret Sharing

Fase 4: Criptografia e Tesseras Seladas

Fase 3: Memórias nas Suas Mãos

Reed-Solomon: Como o Tesseras Sobrevive à Perda de Dados

Os desafios</h2> Reed-Solomon resolve o problema matemático da redundância. Os desafios de engenharia estão em tudo ao redor.</p>

Fase 2: Memórias Sobrevivem

Fase 1: Nós Se Encontram

Fase 0: Fundação Construída

Olá, Mundo

Os desafios</h2>
Reed-Solomon resolve o problema matemático da redundância. Os desafios de engenharia estão em tudo ao redor.</p>
