Nostr tem recebido muita atenção e força por trás desde sua recente adição à lista de plataformas sociais alternativas que são proibidas de promoção no Twitter. E também está ganhando força, pois ficou claro que a compra do Twitter por Elon Musk não mudou fundamentalmente nada sobre a liberdade de expressão na plataforma – os usuários ainda estão sendo banidos por razões inconsistentes e arbitrárias, e as pessoas estão procurando uma alternativa descentralizada que não é algo como Mastodon, onde um operador de servidor ainda tem a capacidade de controlar sua identidade.
Apesar da atenção recente, o protocolo Nostr e a primeira implementação do servidor de retransmissão foram criados no final de 2020 pelo desenvolvedor fiatjaf. Antes da grande explosão de atenção, era apenas um protocolo de nicho silencioso, simplesmente tentando ser uma solução leve para os problemas do Twitter e do Mastodon. Em ambos os sistemas, sua identidade/nome de usuário é simplesmente algo controlado por quem está executando o servidor. Mastodon sendo um sistema federado com vários servidores diferentes, todos conversando entre si, não muda fundamentalmente essa realidade. O servidor de quem você usa para hospedar uma conta tem controle total sobre se você pode usá-lo ou não. Mesmo executando seu próprio servidor, outros operadores de servidor podem colocar na lista negra ou branca quais servidores terão permissão para conversar com os deles. Isso levou a muitos particionamentos no “Fediverse” de diferentes servidores Mastodon e torna a ideia de apenas executar o seu próprio sem sentido. Você ainda pode ser censurado por outros operadores de servidor, impedindo que seus usuários vejam seu conteúdo em seus feeds.
O principal diferenciador entre Nostr e algo como Mastodon é que, em vez de usar um nome de usuário pertencente a um operador de servidor, cada usuário utiliza um par de chaves público/privado para lidar com essa função. Isso é algo que um operador de servidor não pode simplesmente tirar de você ou bloqueá-lo. Este é um dos principais blocos de construção sobre os quais o protocolo Nostr geral é construído.
O próximo é “eventos”. Este é o tipo básico de objeto/dado usado pelos clientes e pelos servidores de retransmissão aos quais os clientes se conectam para enviar e recuperar mensagens. A ideia geral do protocolo é que os clientes enviem eventos para servidores de retransmissão, que por sua vez os armazenam e indexam, e outros clientes podem se comunicar com servidores de retransmissão para solicitar eventos que receberam e armazenaram. No NIP 01 original são definidos três tipos diferentes de eventos:
- 0: Envia metadados sobre um usuário, como nome de usuário, foto, biografia, etc.
- 1: Envia mensagens de texto e conteúdo básico
- 2: Recomenda servidores de retransmissão para as pessoas que seguem o criador do evento se conectarem
Todos os eventos são estruturados de uma forma especificamente definida. Eles incluem a chave pública do criador, um registro de data e hora de quando foram criados, seu tipo (ou tipo na especificação), a carga útil do conteúdo e uma assinatura do criador do evento. Eles também podem ter tags que fazem referência a outros eventos ou usuários e têm um valor de ID que é um hash de tudo, exceto a assinatura do criador (semelhante a um TXID para transações Bitcoin). Isso permite que você garanta que uma mensagem foi realmente criada pelo proprietário da chave pública dentro dela, verificando a assinatura (e a pessoa que possui essa chave se ela não estiver comprometida) e garante que a mensagem não foi alterada após eles assinaram. Assim como você não pode alterar uma transação Bitcoin depois de assinada sem anulá-la, você não pode alterar um evento Nostr depois que o criador a assinou sem que seja uma fraude óbvia.
O sistema de tipo de evento foi expandido substancialmente a partir desse NIP original. Existe um tipo de evento para mensagens diretas criptografadas, estabelecendo uma chave compartilhada combinando a chave privada do remetente com a chave pública do destinatário, o que resulta na mesma chave que você obteria combinando a chave pública do remetente com a chave privada do destinatário (é assim que BIP 47 e Silent Payments funcionam). Também existem tipos para eventos substituíveis e eventos efêmeros. No caso de um evento substituível (obviamente), eles são projetados para que o criador original do evento possa assinar um novo para substituir o antigo. Os servidores de retransmissão que seguem a especificação eliminarão automaticamente o evento mais antigo de seu armazenamento e começarão a servir as versões mais recentes aos clientes após o recebimento. Os eventos efêmeros são projetados para serem transmitidos a qualquer um que assine seu criador quando enviados para o retransmissor, mas os servidores de retransmissão não devem armazená-los. Isso cria a possibilidade de as mensagens serem vistas apenas pelas pessoas quando elas estão online durante sua transmissão. Existe até um tipo de evento para sinalizar uma reação (como curtidas ou emojis) aos eventos de outras pessoas.
Falando desse último, os eventos também podem conter tags. Atualmente, existem tipos de tags para eventos (para fazer referência a um evento Nostr exato), chaves públicas (para marcar ou fazer referência a outros usuários) e assuntos (para emular a funcionalidade, como assuntos de e-mail). Todos eles podem incluir ponteiros para servidores de retransmissão específicos a partir dos quais os dados podem ser obtidos para que os usuários possam realmente interagir entre os servidores, ou seja, um usuário postando seu conteúdo em um servidor de retransmissão pode interagir e fazer referência ao conteúdo criado por outro usuário postando em um servidor de retransmissão diferente de uma forma que permite a qualquer usuário buscar coerentemente todo o encadeamento de interações na ordem adequada e sem grande complexidade em descobrir onde encontrar os dados relevantes.
Dentro do NIP original, é fornecida uma especificação de como os clientes devem interagir com os servidores de retransmissão por meio de uma mensagem/estrutura de dados de assinatura que inclui filtros para quais eventos esse cliente está interessado em receber. Esses filtros podem especificar as chaves públicas dos usuários, eventos exatos, tipos de eventos e até prazos específicos em que eles os desejam com base nos critérios anteriores. Você pode até enviar prefixos de chaves públicas ou IDs de evento, como “1xjisj….” e receba qualquer evento ou eventos de uma chave pública que comece com essa string curta (isso pode ser útil para ocultar de um servidor de retransmissão o que você realmente deseja visualizar).
No geral, o protocolo é um esquema generalizado e básico para passar mensagens entre usuários que cobre coisas importantes, como garantir a integridade das mensagens e quem as enviou com o uso de identidades de chave pública, além de facilitar a infraestrutura no back-end para servidores de retransmissão que podem ser extremamente centralizados ou permitir que um usuário execute seu próprio servidor de retransmissão pessoal, interagindo perfeitamente entre si e não causando caos maciço no caso de um usuário ser banido de um servidor de retransmissão. Eles podem mudar para outro ou executar o seu próprio e sua desplataforma do servidor anterior não os faz perder sua identidade digital ou seguidores porque eles ainda mantêm o controle sobre sua chave privada e os usuários podem autenticá-la ao encontrá-los em outro lugar.
Os servidores de retransmissão também podem operar da maneira que quiserem. Eles podem operar de graça, podem cobrar micropagamentos para postar ou baixar mensagens e existe até um NIP para exigir prova de trabalho no estilo hashcash para enviar uma mensagem. Eles podem ser um único servidor de retransmissão para hospedar e servir apenas suas postagens para outros usuários, ou podem ser um servidor executado em grande escala, como o Twitter ou o Reddit (os clientes podem exibir e organizar as informações da maneira que quiserem, o que permite emular essencialmente qualquer rede social plataforma de mídia que existe hoje). Tudo isso pode interoperar perfeitamente e sem ser capaz de excluir um usuário. Você pode impedi-los de postar conteúdo em seu servidor de retransmissão, mas, em última análise, não pode impedi-los de visualizar o conteúdo que você hospeda em seu servidor de retransmissão ou impedir que outros usuários encontrem seu conteúdo em outros servidores.
É um protocolo muito simplista com um grande espaço de design aberto para as pessoas construírem, garantindo que os usuários sempre possam interagir uns com os outros, independentemente de qual servidor de retransmissão individual os operadores escolherem hospedar ou não. Esta é simultaneamente a sua maior força e maior fraqueza. Embora garanta a liberdade para os desenvolvedores criarem sem restrições rígidas por um protocolo complicado, também há muitos problemas inerentes que não são tratados pelo próprio protocolo.
No próximo artigo que escrevo, abordarei alguns dos problemas que vejo ocorrendo e possíveis soluções, mas, por enquanto, direi apenas que em termos da simplicidade do design e das possibilidades que ele abre para as pessoas build, Nostr fez um trabalho muito bom, considerando que é a ideia de uma pessoa e apenas um punhado de pessoas realmente contribuiu para a especificação do protocolo em si até agora.
Este é um post de convidado por Shinobi. As opiniões expressas são inteiramente próprias e não refletem necessariamente as da BTC Inc ou da Bitcoin Magazine.
Fonte: bitcoinmagazine.com
