Nostr

Anna encontra no Nostr autores que quer seguir. Mais tarde, a aplicação deixa de lhe agradar. Se usar a mesma chave privada ou um dispositivo de assinatura ligado de forma segura noutra aplicação, pode manter a identidade. A chave pública permite reconhecê-la e verificar assinaturas; a privada permite assinar como Anna. Daí a diferença fundamental entre npub e nsec. Segundo o NIP-19, representam as chaves pública e privada na codificação Bech32. Os NIPs são documentos numerados que descrevem as regras e extensões do Nostr. Codificação não é encriptação: um nsec não é um simples endereço de perfil que se possa partilhar com qualquer pessoa. Manter a identidade também não garante que a nova aplicação encontre todas as publicações antigas ou importe todas as definições. [2] [7]

A aplicação, chamada cliente, assina a publicação e envia-a aos relays escolhidos. Um relay é um servidor que recebe mensagens e as guarda ou transmite segundo as suas regras. A aplicação de Petr liga-se a relays para pedir publicações do seu interesse. Não existe um servidor central único nem a obrigação de cada servidor copiar tudo. Tecnicamente, cliente e relay comunicam por WebSocket, uma ligação mantida aberta: EVENT transporta a mensagem, REQ inicia uma subscrição e OK comunica aceitação ou recusa. Mesmo um OK positivo não confirma a entrega a Petr nem o armazenamento permanente. EOSE marca o fim dos resultados já guardados para a consulta; a subscrição pode continuar com novas mensagens. [1] [7]

Quando Petr recebe uma mensagem, a aplicação verifica se a assinatura corresponde à chave pública indicada e se os dados assinados não mudaram. Isso não prova a veracidade da mensagem nem a identidade civil do autor. O próprio autor indica a hora de criação, pelo que não é um carimbo temporal independente. Para quem quiser aprofundar: o registo chamado event contém pubkey, created_at, kind, tags e content, ou seja, chave, hora, tipo, etiquetas e conteúdo. SHA-256 transforma a representação rigorosamente definida desses dados em um valor curto de verificação chamado id. Ele permite detectar alterações nos dados assinados. O campo sig contém uma Schnorr Signature conforme o BIP340 na curva secp256k1. Significa que o detentor da chave correspondente assinou os dados, não que a afirmação mereça confiança. [1]

É difícil memorizar uma chave pública longa. O NIP-05 permite associá-la a um identificador com aspeto de endereço de e-mail. A aplicação pergunta ao domínio em questão qual é a chave associada ao nome e compara a resposta com a chave do perfil. Verifica essa ligação ao domínio, não automaticamente o nome real, a reputação ou a fiabilidade de alguém. O operador do domínio pode alterar a associação. Se Anna já segue uma pessoa, a chave pública original deve continuar a ser a referência; atribuir o mesmo nome a outra chave não deve mudar discretamente quem ela segue. Pseudonimato significa usar uma identificação persistente em vez do nome civil, não uma garantia de anonimato. [3]

Petr não precisa de descarregar todas as mensagens. Envia um filtro, por exemplo para determinados autores e um tipo de publicação. As diferentes condições de um filtro ligam-se por AND: todas têm de ser satisfeitas. Vários valores permitidos numa condição são alternativas OR, tal como vários filtros num único REQ. Basta satisfazer um desses filtros. limit restringe o conjunto inicial de resultados guardados, não automaticamente as mensagens futuras da subscrição. O NIP-01 usa chaves hexadecimais em eventos e filtros, não o formato npub apresentado ao utilizador. Uma pesquisa vazia pode dever-se ao filtro, ao servidor escolhido ou ao seu histórico; não prova que a publicação não exista em lado nenhum. [1]

Anna muda a descrição do perfil e quer que os outros vejam a nova. O Nostr distingue, por isso, o que os relays devem conservar. Nos eventos substituíveis, selecionam o registo mais recente para o mesmo par pubkey e kind. Os eventos endereçáveis acrescentam o valor da etiqueta d, distinguindo, por exemplo, documentos do mesmo autor. Se registos substituíveis tiverem a mesma hora, recomenda-se manter o id lexicograficamente menor, o primeiro na ordenação da sua representação. Nem se espera que os eventos temporários, chamados ephemeral, sejam guardados. São convenções e o comportamento dos relays pode variar. O Nostr não é, portanto, um livro de registos em que toda a rede concorda com uma única história imutável. [1]

Anna percebe que publicou algo que queria manter privado. O NIP-09 permite enviar um pedido de eliminação assinado. Antes de o executar, o cliente deve verificar que o pedido e a publicação original pertencem à mesma chave pública; outra pessoa não pode apagar a publicação de Anna apenas por a indicar. Os servidores e aplicações que cooperam podem remover o conteúdo ou deixar de o mostrar. O pedido não elimina todas as cópias, capturas de ecrã ou arquivos independentes. Ocultar uma publicação numa aplicação também não diz se outro servidor continua a disponibilizá-la. O que publica importa mais do que a existência de um botão Apagar. [4]

Qualquer pessoa que obtenha uma publicação pública pode lê-la; a assinatura não esconde o conteúdo. As mensagens privadas usam regras adicionais. O NIP-44 descreve a encriptação do conteúdo, enquanto o NIP-17 trata do seu empacotamento e entrega com outras camadas de proteção. Isso não assegura anonimato automático: endereços de rede, horários e comportamento da aplicação podem continuar a revelar informações. Esta encriptação também não oferece forward secrecy, proteção das conversas antigas caso uma chave de longa duração seja comprometida mais tarde. Quem obtenha a chave privada necessária e mensagens encriptadas anteriormente registadas poderá ler também comunicações passadas. Verifique as extensões realmente suportadas pela aplicação; a designação «Nostr» não basta para descrever a sua privacidade. [5] [6]