# Nosdrive: uma proposta conceitual para armazenamento de arquivos sobre Nostr
fiatjaf (npub180c…h6w6) , imaginei um projeto chamado Nosdrive, um cliente Nostr voltado especificamente para utilizar a infraestrutura do Nostr como uma camada de armazenamento e sincronização de arquivos distribuída, criptografada e replicada.
A proposta não seria simplesmente transformar o Nostr em um "Google Drive descentralizado", mas construir uma abstração de sistema de arquivos sobre eventos Nostr, preservando tanto quanto possível as propriedades fundamentais do protocolo.
1. Motivação
O Nostr possui algumas características particularmente interessantes para armazenamento distribuído: identidade baseada em chaves públicas, eventos assinados criptograficamente, publicação para múltiplos relays, ausência de dependência de um servidor central, possibilidade de sincronização entre clientes e interoperabilidade entre diferentes implementações.
A ideia do Nosdrive seria explorar essas propriedades para criar uma camada de armazenamento na qual os arquivos não pertençam exclusivamente a um servidor específico, mas sejam representados por objetos e eventos Nostr que podem ser publicados e replicados em diferentes relays.
Para o usuário, a experiência seria semelhante à de qualquer serviço tradicional de armazenamento em nuvem. Ele poderia criar pastas, adicionar arquivos, renomeá-los, movê-los, excluí-los, recuperar versões anteriores e sincronizar o conteúdo entre diferentes dispositivos. A diferença estaria na infraestrutura utilizada para realizar essas operações.
2. Modelo fundamental
O modelo mais simples que imagino consiste em transformar o arquivo em conteúdo criptografado, dividir esse conteúdo em partes menores e representar essas partes por eventos Nostr.
O processo seria aproximadamente o seguinte: o usuário seleciona um arquivo, o cliente o criptografa localmente, divide o resultado em chunks de tamanho adequado, publica esses chunks em relays e publica também os metadados necessários para que outro cliente consiga descobrir, verificar e reconstruir o arquivo.
O arquivo não precisaria ser representado por um único evento de tamanho potencialmente enorme. Isso seria particularmente importante porque os relays possuem diferentes limites e políticas de armazenamento.
Cada chunk poderia possuir um identificador derivado criptograficamente do arquivo, de sua posição e de seu conteúdo. Dessa maneira, o cliente conseguiria verificar a integridade de cada parte e identificar quais chunks estão faltando ou foram alterados.
3. Separação entre identidade e armazenamento
Um ponto importante da proposta é não utilizar diretamente a nsec como chave de criptografia dos arquivos.
A nsec representa a identidade privada do usuário no Nostr e é utilizada para assinar eventos. Utilizá-la diretamente como chave de armazenamento criaria um acoplamento desnecessário entre identidade e dados.
O Nosdrive poderia utilizar uma chave mestra de armazenamento independente da nsec, protegida pelo mecanismo de autenticação ou recuperação escolhido pelo cliente. A partir dela, poderiam ser derivadas ou geradas chaves individuais para cada arquivo.
Dessa forma, cada arquivo poderia possuir sua própria chave de criptografia. Isso permitiria compartilhar ou revogar o acesso a um arquivo específico sem comprometer os demais.
Também tornaria possível modificar futuramente o sistema de autenticação sem necessariamente precisar recriptografar todo o armazenamento do usuário.
4. Representação do filesystem
O conceito de "pasta" não precisaria existir nativamente no protocolo Nostr.
O Nosdrive poderia implementar essa estrutura como uma camada de aplicação. Uma pasta seria simplesmente um objeto identificado por uma chave ou identificador, contendo informações como seu nome e a referência à pasta que a contém.
Da mesma maneira, um arquivo seria representado por um objeto contendo informações como seu identificador, nome, tipo MIME, tamanho, hash do conteúdo, quantidade de chunks e informações necessárias para a descriptografia.
A relação entre esses objetos permitiria ao cliente reconstruir a estrutura de diretórios.
Portanto, uma pasta não seria necessariamente uma entidade especial do Nostr. Seria uma abstração criada pelo Nosdrive a partir de eventos e relações entre objetos.
Isso permitiria inclusive que diferentes clientes apresentassem a mesma estrutura de armazenamento de maneiras diferentes, desde que interpretassem corretamente o protocolo utilizado.
5. Eventos de metadados
Um arquivo precisaria de algum tipo de evento de metadados para que o cliente pudesse saber como reconstruí-lo.
Esse evento poderia conter informações como o identificador do arquivo, nome, tipo MIME, tamanho, hash do conteúdo, tamanho dos chunks, quantidade de chunks, identificador da pasta pai e informações relacionadas à criptografia.
Os dados efetivos do arquivo seriam armazenados em eventos separados, correspondentes aos chunks.
Essa separação permitiria que um cliente encontrasse primeiro os metadados e depois determinasse exatamente quais chunks precisa buscar.
O formato exato desses eventos precisaria ser definido cuidadosamente. A intenção não seria criar uma estrutura arbitrária, mas investigar como isso poderia ser representado de maneira compatível com os mecanismos existentes do Nostr e, caso necessário, através de novos NIPs.
6. Criptografia
A criptografia ocorreria localmente antes que qualquer conteúdo fosse enviado aos relays.
O relay nunca precisaria receber o arquivo em plaintext. Ele receberia somente o conteúdo criptografado e, dependendo da implementação, alguns metadados que também poderiam ser protegidos.
Isso permitiria que o armazenamento fosse essencialmente zero-knowledge em relação ao conteúdo dos arquivos.
Um relay não precisaria conhecer o conteúdo de um documento, por exemplo. Dependendo do nível de proteção aplicado aos metadados, também poderia não saber o nome do arquivo ou sua localização dentro da estrutura de pastas.
O nível exato de privacidade seria uma decisão do protocolo. Existe um equilíbrio entre ocultar metadados e permitir que os clientes pesquisem e sincronizem os dados eficientemente.
7. Compartilhamento
Uma das partes mais interessantes da proposta seria o compartilhamento entre identidades Nostr.
Como cada arquivo teria sua própria chave de criptografia, o proprietário poderia compartilhar essa chave com outra identidade sem precisar compartilhar sua nsec.
O cliente poderia utilizar mecanismos criptográficos apropriados para encapsular a chave do arquivo para a identidade do destinatário.
Isso permitiria operações como compartilhar um arquivo ou uma pasta com outra identidade, conceder diferentes níveis de acesso e posteriormente revogar esse acesso.
O Nostr já possui um mecanismo de identidade baseado em chaves públicas, então seria interessante investigar se essa característica poderia servir como base natural para um sistema de permissões de arquivos.
8. Replicação
Um arquivo não deveria depender de um único relay.
O cliente poderia publicar os eventos relacionados ao arquivo em múltiplos relays. Dessa maneira, a perda ou indisponibilidade de um relay não necessariamente resultaria na perda do arquivo.
O usuário poderia inclusive configurar um fator de replicação. Por exemplo, poderia solicitar que seus arquivos fossem mantidos em pelo menos três relays diferentes.
O cliente poderia consultar múltiplos relays e obter de cada um os chunks que estiverem disponíveis. Como cada chunk possuiria mecanismos de verificação de integridade, o cliente poderia rejeitar dados incorretos e tentar obtê-los de outro relay.
Isso transformaria a redundância em uma propriedade da aplicação, e não em uma característica que precisaria ser fornecida individualmente por cada relay.
9. O problema dos relays
Esse é provavelmente o maior desafio da proposta.
Relays Nostr não são necessariamente sistemas de armazenamento permanente. Um relay pode impor limites de tamanho, rejeitar determinados eventos, apagar eventos antigos, limitar armazenamento por usuário, possuir políticas próprias de retenção, ficar offline ou simplesmente desaparecer.
Por isso, o Nosdrive precisaria tratar os relays como provedores de armazenamento potencialmente não confiáveis.
A disponibilidade dos arquivos dependeria da combinação de criptografia, verificação de integridade, fragmentação e replicação.
Um relay poderia perder alguns chunks sem necessariamente causar a perda definitiva do arquivo, desde que existissem cópias suficientes em outros relays.
Isso também significa que o Nosdrive precisaria diferenciar claramente disponibilidade de persistência. Publicar um arquivo em um relay não significaria que aquele arquivo ficará armazenado ali indefinidamente.
10. Relays especializados
Uma possibilidade interessante seria o surgimento de relays especializados em armazenamento.
Esses relays poderiam anunciar capacidades específicas, como tamanho máximo de eventos, capacidade de armazenamento, política de retenção, custo, disponibilidade e NIPs suportados.
O Nosdrive poderia consultar essas informações e escolher automaticamente os relays mais adequados para armazenar determinado tipo de conteúdo.
Isso poderia criar uma categoria de infraestrutura especializada em armazenamento sobre Nostr sem necessariamente modificar o conceito fundamental de relay.
O Nostr continuaria fornecendo identidade, eventos e comunicação, enquanto esses relays ofereceriam uma infraestrutura otimizada para persistência de dados.
11. Deduplicação
A utilização de hashes também permitiria implementar deduplicação.
Se o cliente identificar que determinado conteúdo já está armazenado, poderia evitar publicar novamente exatamente os mesmos chunks.
Inicialmente, isso poderia ser limitado ao armazenamento de uma única identidade, reduzindo as implicações de privacidade.
Uma deduplicação entre diferentes usuários seria tecnicamente interessante, mas exigiria uma análise muito mais cuidadosa, porque a existência de determinado conteúdo poderia acabar sendo inferida por terceiros.
12. Versionamento
O modelo baseado em objetos e eventos também poderia permitir versionamento.
Quando um arquivo fosse alterado, o cliente poderia criar uma nova versão associada ao mesmo identificador lógico do arquivo, mantendo referências para as versões anteriores.
Isso permitiria recuperar uma versão antiga de um documento sem depender de um servidor central.
O versionamento também poderia facilitar a sincronização entre dispositivos, pois um cliente poderia identificar exatamente quais versões já possui e baixar apenas os dados que ainda não estão disponíveis localmente.
13. Sincronização
O Nosdrive poderia utilizar os relays como uma camada de sincronização entre dispositivos.
Quando um usuário adicionasse ou modificasse um arquivo em um computador, os eventos correspondentes seriam publicados.
Outro dispositivo pertencente à mesma identidade poderia consultar os relays, descobrir os novos eventos e baixar apenas os dados que ainda não possui.
Isso permitiria uma experiência semelhante à de serviços como Google Drive, OneDrive ou Dropbox, mas sem depender de um único servidor central para manter o estado do armazenamento.
14. Eventual consistency
O sistema provavelmente funcionaria melhor utilizando um modelo de consistência eventual.
Dois dispositivos poderiam trabalhar offline e posteriormente publicar suas alterações.
Quando voltassem a se conectar, os clientes poderiam reconciliar o estado com base nos eventos existentes.
Conflitos mais complexos, como dois dispositivos modificando simultaneamente o mesmo arquivo ou movendo o mesmo objeto para locais diferentes, exigiriam uma estratégia explícita de resolução de conflitos.
Isso poderia ser tratado pela própria camada do Nosdrive, sem necessariamente exigir alterações fundamentais no protocolo Nostr.
15. Exclusão de arquivos
A exclusão também apresenta uma questão importante.
Como eventos podem existir em múltiplos relays independentes, publicar uma instrução para apagar um arquivo não garante que os dados físicos desaparecerão imediatamente de todos os lugares.
O Nosdrive poderia utilizar eventos de exclusão ou tombstones para indicar que determinado objeto não deve mais ser considerado parte do filesystem.
O cliente deixaria de apresentar o arquivo ao usuário, enquanto os relays poderiam decidir quando remover fisicamente os dados associados.
Isso cria uma distinção entre exclusão lógica e exclusão física.
A exclusão lógica poderia ser controlada pelo protocolo do Nosdrive, enquanto a exclusão física dependeria das políticas dos relays.
16. Segurança
O modelo deveria assumir que os relays são potencialmente maliciosos ou pouco confiáveis.
Um relay poderia fornecer um chunk incorreto, omitir dados, censurar determinados eventos ou tentar modificar conteúdo.
Por isso, cada chunk precisaria ser verificável criptograficamente.
O cliente poderia calcular o hash do conteúdo recebido e compará-lo com o valor esperado. Se o resultado não correspondesse, o cliente poderia ignorar aquele chunk e tentar recuperá-lo de outro relay.
A assinatura dos eventos também ajudaria a garantir a autenticidade dos metadados e das operações realizadas pelo proprietário.
Dessa maneira, o relay poderia funcionar essencialmente como um armazenamento não confiável, enquanto a segurança e a validação seriam responsabilidade do cliente e dos mecanismos criptográficos.
17. A pergunta fundamental
A ideia depende de uma questão central:
O modelo de eventos do Nostr é suficientemente flexível para representar um sistema de armazenamento distribuído baseado em chunks sem violar as premissas fundamentais do protocolo?
Se a resposta for sim, o Nosdrive poderia inicialmente ser implementado como uma aplicação construída sobre Nostr, sem exigir uma alteração profunda no protocolo.
Se a resposta for não, seria interessante identificar exatamente qual parte da arquitetura representa o obstáculo e se seria melhor criar um protocolo complementar, interoperável com Nostr, especificamente para armazenamento.
18. MVP proposto
Eu não começaria com vídeos de dezenas de gigabytes, sincronização complexa ou compartilhamento avançado.
O primeiro protótipo poderia se limitar a arquivos relativamente pequenos.
O cliente receberia um arquivo, criptografaria seu conteúdo localmente, dividiria o resultado em chunks, publicaria os chunks em alguns relays e publicaria os metadados necessários para reconstrução.
Depois, um segundo cliente poderia consultar os relays, encontrar os metadados, localizar os chunks correspondentes, verificar sua integridade, reconstruir o conteúdo criptografado e finalmente descriptografar o arquivo.
Se esse fluxo básico funcionar de maneira robusta, seria possível adicionar progressivamente pastas, sincronização, versionamento, compartilhamento, deduplicação e mecanismos mais sofisticados de replicação.
19. Arquitetura conceitual
Eu imagino o Nosdrive como uma camada construída sobre o Nostr.
A interface do Nosdrive seria responsável por apresentar arquivos, pastas, buscas e operações de gerenciamento.
Uma camada de filesystem seria responsável por representar arquivos, pastas, relações, versões e permissões.
Uma camada de armazenamento seria responsável por criptografia, divisão em chunks, hashes, reconstrução e replicação.
Por baixo de tudo estaria o Nostr, fornecendo identidade, assinatura de eventos, publicação e comunicação com os relays.
Assim, o Nostr não precisaria necessariamente "saber" que está armazenando um arquivo. Para o protocolo, continuariam sendo eventos. O significado de arquivo, pasta, versão ou chunk seria definido pela camada de aplicação.
20. Conclusão
A ideia, resumidamente, é utilizar Nostr como uma camada de identidade, comunicação e distribuição de eventos, construindo sobre ela um sistema de armazenamento de arquivos criptografados, fragmentados e replicados.
O objetivo não seria substituir diretamente sistemas de armazenamento distribuído existentes, mas investigar se as propriedades do Nostr podem ser utilizadas para criar uma experiência semelhante a uma nuvem, porém sem depender de uma única entidade para controlar a identidade e o estado dos dados.
O ponto que mais me interessa é a possibilidade de representar um filesystem inteiro como uma coleção de eventos Nostr, mantendo a estrutura de arquivos como uma abstração da aplicação.
fiatjaf (npub180c…h6w6), você acha que esse modelo faz sentido dentro do paradigma do Nostr?
Mais especificamente, existe alguma limitação fundamental do protocolo, dos eventos ou da arquitetura dos relays que tornaria essa abordagem inadequada? Ou você acha que seria possível construir algo desse tipo como uma camada de aplicação sobre Nostr, talvez utilizando NIPs específicos para storage e chunking?
