AI researcher and product designer building at the edge of computer science and mental health. Zola 2026-01-15T00:00:00+00:00 https://brennercruvinel.blog/tags/arquitetura/atom.xml 2026-01-15T00:00:00+00:00 2026-01-15T00:00:00+00:00 Brenner Cruvinel https://brennercruvinel.blog/blog/nest-vector-db-soberano/ <p>compatilhando aqui o concept de uma aplicação que estou trabalhando, cansado de ter que ficar fazendo gambiarra com vector db sem estabilidade:</p> <h2 id="nest">nest</h2> <p>nest e um vector db soberano de arquivo unico. content-addressable, offline-first, hash-verified. python constroi o arquivo, rust serve o arquivo. o enderecamento e <code>nest://content_hash/chunk_id</code>: voce cita pelo conteudo, nao pela localizacao. se o conteudo muda o hash muda, e e impossivel receber coisa diferente da que voce pediu.</p> <h3 id="as-notas">as notas</h3> <ul> <li>[[hash-content-addressing]], a familia mais proxima do nest. content-addressable storage (IPFS), como o <code>nest://content_hash/chunk_id</code> funciona, e Git como o exemplo mais cotidiano de snapshot imutavel e verificavel. inclui como o nest difere de Git e de IPFS.</li> <li>[[delta-binario-snapshots]], a opcao mais tecnica de distribuir versoes via diff binario (<code>bsdiff</code>, <code>zstd --patch-from</code>, <code>xdelta</code>). a ideia do patch, e o senao: build deterministico que reordena por dentro pode estourar o diff. mais fragil que o sharding.</li> <li>[[prova-imutabilidade-timestamp]], a camada criptografica alem do hash pelado. assinatura e certificados (PKI, TLS), timestamping (RFC 3161, OpenTimestamps), e blockchain, que pro caso de papers seria canhao pra matar mosquito.</li> </ul> <h2 id="hash-como-identidade-content-addressing">hash como identidade, content-addressing</h2> <p>a familia mais proxima do nest. a ideia central e uma so: o hash do conteudo vira o endereco do conteudo. voce nao aponta pra um lugar, aponta pra uma coisa. se a coisa muda, o endereco muda. e dai cai tudo o que importa pro nest, imutabilidade, verificacao, citacao por conteudo.</p> <h3 id="content-addressable-storage-ipfs-e-o-proprio-nest">content-addressable storage (IPFS, e o proprio nest)</h3> <p>aqui o endereco do dado <strong>e</strong> o hash dele. em vez de “me de o arquivo em tal pasta”, que pode ter sido trocado sem voce saber, voce diz “me de o arquivo cujo conteudo tem este hash”. e e impossivel receber coisa diferente: se viesse diferente, teria outro hash. a verificacao nao e um passo extra, ela e a propria forma de pedir.</p> <p>IPFS e a rede distribuida que faz isso em escala.</p> <h4 id="como-o-nest-funciona">como o nest:// funciona</h4> <p>o <code>nest://content_hash/chunk_id</code> do nest e exatamente esse principio. voce cita pelo conteudo, nao pela localizacao.</p> <ul> <li><code>content_hash</code> identifica o blob inteiro pelo hash do que ele contem</li> <li><code>chunk_id</code> aponta o pedaco dentro daquele blob</li> </ul> <p>a consequencia pratica: uma citacao no nest nao quebra quando o arquivo muda de pasta, de disco, de maquina. ela so vale pra aquele conteudo. se o conteudo mudou, o hash mudou, e voce sabe na hora que esta falando de outra coisa.</p> <h3 id="git-o-exemplo-mais-cotidiano">Git, o exemplo mais cotidiano</h3> <p>voce usa todo dia e talvez nao tenha percebido que e exatamente isso. cada commit e identificado por um hash do conteudo. quando voce da <code>git commit</code>, esta tirando uma foto selada do codigo naquele instante. se alguem alterar a historia, os hashes nao batem e o Git acusa.</p> <p>e o exemplo mais cotidiano de “snapshot imutavel e verificavel” que existe.</p> <h3 id="como-o-nest-difere">como o nest difere</h3> <p>duas comparacoes que delimitam o nest dentro da familia.</p> <h5 id="nest-x-git">nest x Git</h5> <table><thead><tr><th></th><th>sela o que</th><th>pra que serve</th></tr></thead><tbody> <tr><td>Git</td><td>codigo</td><td>navegar versoes</td></tr> <tr><td>nest</td><td>conhecimento vetorizado</td><td>busca</td></tr> </tbody></table> <p>Git sela codigo e e feito pra voce navegar versoes. o nest sela conhecimento vetorizado pra busca. mesmo mecanismo de hash, finalidade diferente.</p> <h5 id="nest-x-ipfs">nest x IPFS</h5> <p>mesmo principio de content-addressing, escala diferente. IPFS e a rede distribuida que faz isso em escala, muitas maquinas. o nest e o caso local de arquivo unico. um arquivo soberano, offline-first, com o mesmo “o endereco e o hash” por dentro.</p> <h3 id="por-que-isso-e-a-familia-mais-proxima">por que isso e a familia mais proxima</h3> <p>das analogias que coletei, essa e a que descreve o nest sem metafora. Git e timestamping e blockchain todos usam hash de conteudo, mas pra outras finalidades. content-addressable storage usa hash de conteudo pela mesma razao que o nest: para que pedir o dado e verificar o dado sejam a mesma operacao.</p> <h2 id="delta-binario-por-cima-de-snapshots">delta binario por cima de snapshots</h2> <p>a opcao mais tecnica pra distribuir versoes do nest sem rebaixar o arquivo inteiro toda vez. funciona, mas tem um senao que so se descobre testando. mais fragil que o sharding.</p> <h3 id="a-ferramenta">a ferramenta</h3> <p>existem ferramentas de diff binario que calculam a <em>diferenca</em> entre o arquivo de ontem e o de hoje e produzem um “patch” pequeno:</p> <ul> <li><code>bsdiff</code></li> <li><code>zstd --patch-from</code></li> <li><code>xdelta</code></li> </ul> <h3 id="a-ideia-do-patch">a ideia do patch</h3> <p>o cliente que ja tem a versao de ontem baixa so o patch e reconstroi a de hoje localmente. e como o teu sistema operacional atualiza sem rebaixar o SO inteiro. so o delta desce pela rede, a maquina monta o resto.</p> <h3 id="o-senao-pro-nest">o senao pro nest</h3> <p>aqui esta a parte fragil. se o build deterministico reordena coisas internamente quando voce adiciona conteudo, e formatos comprimidos/indexados costumam reorganizar bastante, o diff pode sair grande mesmo pra pouca mudanca. voce muda um chunk, o formato remexe o indice inteiro, e o patch deixa de ser pequeno.</p> <p>so vale se o formato for “append-friendly”, quer dizer, se adicionar conteudo no fim nao bagunca o que ja estava la. e isso voce so sabe testando.</p> <p>seguimos… quem pilhar, deixei aberto no git.</p>