BTC

$62311.015

-2.22%

ETH

$3008.945

-2.03%

BNB

$582.999

-1.87%

XRP

$0.528

-2.20%

Recursos Educacionais

O novo ano das mídias sociais: princípios Nostr e questões-chave de gestão

4 de fevereiro de 2023 - por volta 15 minutos minutos para ler
Novos designs de redes sociais sob a Quinta Direita têm sido explorados há anos, sem nenhum sinal de adoção em massa. No ano passado, com o desenvolvimento contínuo da tecnologia de criptografia e as preocupações com a aquisição do Twitter por Musk, a rede social descentralizada abriu novas oportunidades.
Os problemas que estas redes sociais estão a tentar resolver: podem incluir o reforço da censura, tornar a moderação de conteúdos mais flexível e reduzir o poder das grandes empresas de redes sociais para moldar e monitorizar o que as pessoas falam online, entre outras coisas.
À medida que novas plataformas surgem e crescem, a escolha de redes sociais alternativas muitas vezes envolve considerações políticas. Sites como Getr, Parler, Gab e Truth Social atendem à direita ao se promoverem como alternativas de liberdade de expressão ao Twitter.
O que vamos discutir hoje é Nostr-damus, um novo protocolo de mídia social que tem recebido muita atenção recentemente e é um tanto inovador. Estes incluem os princípios técnicos da Nostr, questões-chave de gestão a serem resolvidas e como incentivar o relé a continuar a operar.
O novo ano das mídias sociais: princípios Nostr e questões-chave de gestão

Visão geral do Nostr

Lançado em 2020, Nostr é um protocolo descentralizado que permite aos usuários possuir suas identidades e verificar postagens usando assinaturas digitais usando criptografia de chave pública-privada. Essas postagens são então propagadas para uma rede interconectada de servidores. O protocolo não usa blockchain, que foi considerado nos primeiros experimentos muito lento para redes sociais. Mas existem semelhanças estruturais, e Nostr encontrou um nicho inicial na multidão criptográfica com seu espírito libertário e de código aberto.

Mastodonte vs.

O protocolo Nostr e o primeiro servidor de retransmissão foram criados pelo desenvolvedor fiatjaf no final de 2020. Antes de ganhar ampla atenção, o Nostr era um protocolo de nicho silencioso com o objetivo de ser uma solução leve para os problemas do Twitter e do Mastodon.

Mastodon, uma rede de código aberto fundada em 2016, permite que qualquer pessoa configure um servidor. O design é frequentemente descrito como “federado” e pode ou não cair na linha confusa de “Web3”, dependendo de como isso é definido. O Mastodon permite que os usuários participem de comunidades selecionadas com regras personalizadas de moderação de conteúdo. Actualmente, o número de utilizadores registados atingiu mais de 200 milhões e tornou-se um porto seguro para liberais, jornalistas e académicos.

In Twitter e Mastodonte sistemas, identidades/nomes de usuário são controlados por quem executa o servidor.

A principal diferença no Nostr é que cada usuário usa um par de chaves pública/privada para lidar com a função, em vez de usar um nome de usuário de propriedade do operador do servidor, tornando o Nostr resistente à censura. Este é um dos principais blocos de construção para a construção de todo o protocolo Nostr.

O novo ano das mídias sociais: princípios Nostr e questões-chave de gestão

Evento: este é o tipo básico de objeto/dado usado pelos clientes e pelos servidores de retransmissão aos quais eles se conectam para enviar e recuperar mensagens. A ideia geral do protocolo é que os clientes enviem eventos para um servidor de retransmissão, que os armazena e indexa, e outros clientes podem se comunicar com o servidor de retransmissão para solicitar eventos que receberam e armazenaram. No original PIN 01, três tipos de eventos diferentes foram definidos:

  • Envie metadados sobre o usuário, como nome de usuário, foto, biografia, etc.
  • Envie SMS e conteúdo básico
  • Recomende o servidor de retransmissão para pessoas que seguem o criador do evento para se conectar

Todos os eventos são estruturados de uma forma especificamente definida. Inclui a chave pública do criador, o carimbo de data/hora da criação, o tipo (ou tipo na especificação), a carga útil do conteúdo e a assinatura do criador do evento. Alternativamente, pode haver tags que se referem a outros eventos ou usuários e possuem um valor de ID que é um hash de tudo, exceto a assinatura do criador (semelhante ao TXID de uma transação Bitcoin).

Isso permite que os usuários verifiquem a assinatura (e quem possui a chave, se ela não tiver sido comprometida) para garantir que a mensagem foi realmente criada pelo proprietário da chave pública nela contida e que a mensagem não foi alterada desde que eles assinaram isto.

Assim como uma transação Bitcoin não pode ser alterada depois de assinada sem invalidá-la, um usuário não pode alterá-la após o criador da transação. Nostr evento o assinou sem torná-lo uma fraude óbvia.

O sistema de tipo de evento foi expandido consideravelmente em relação ao original NIP. Existe um tipo de evento para mensagens criptografadas diretas que constroem um segredo compartilhado combinando a chave privada do remetente com a chave pública do destinatário, cujo resultado é o mesmo que você obtém combinando a chave pública do remetente com a chave privada do destinatário as chaves são iguais (é assim que funcionam o BIP 47 e os pagamentos silenciosos).

Existem também eventos substituíveis e tipos de eventos efêmeros. No caso de eventos substituíveis (obviamente), eles são projetados para que o criador original do evento possa assinar um novo evento para substituir o antigo. Os servidores de retransmissão que seguem esta especificação excluirão automaticamente eventos antigos de seu armazenamento e começarão a fornecer versões mais recentes aos clientes após o recebimento.

Eventos efêmeros são projetados de tal forma que, quando enviados a um retransmissor, serão transmitidos para qualquer pessoa assinante de seu criador, mas o servidor de retransmissão não deve armazená-los. Isso cria a possibilidade de que apenas quem está online veja a mensagem durante sua transmissão. Existe até um tipo de evento para representar reações aos eventos de outras pessoas (como curtidas ou emojis).

Falando na última pergunta, os eventos também podem conter tags. Atualmente, existem tipos de tags para o Evento (referindo-se a um evento Nostr exato), Chave pública (para marcar ou referir-se a outro usuário), e Assunto (para imitar a funcionalidade, como o assunto de um email).

O novo ano das mídias sociais: princípios Nostr e questões-chave de gestão

Tudo isso pode incluir ponteiros para servidores de retransmissão específicos dos quais os dados são buscados para que os usuários possam realmente interagir em servidores diferentes, ou seja, um usuário publica seu conteúdo em um servidor de retransmissão, conteúdo que pode ser interagido e referenciado por outro usuário em um servidor de retransmissão diferente. servidor de retransmissão para que qualquer usuário possa obter de forma coerente todo o thread de interação na ordem correta, sem ter que descobrir onde os dados relevantes estão em um grande número de operações complexas.

No original NIP, foi fornecida uma especificação de como um cliente interage com um servidor de retransmissão assinando uma estrutura de mensagens/dados que inclui filtros para quais eventos o cliente está interessado em receber. Esses filtros podem especificar a chave pública do usuário, o evento exato, o tipo de evento ou até mesmo um período de tempo específico que desejam com base em critérios anteriores.

Os usuários podem até enviar chaves públicas ou prefixos de IDs de eventos, como “1xjisj…” e receber qualquer um ou mais eventos de uma chave pública começando com essa sequência curta (isso é útil para ocultar dos servidores de retransmissão o que você realmente deseja ver) .

No geral, o protocolo é um esquema geral muito simples para passar mensagens entre usuários, cobrindo coisas importantes como garantir a integridade das mensagens e usar identidades de chave pública para enviar mensagens, ao mesmo tempo que facilita que os servidores de retransmissão da infraestrutura final possam ser altamente centralizados ou permitir que os usuários executem seus próprios servidores de retransmissão pessoais, interagindo perfeitamente entre si e sem causar caos massivo no caso de os usuários serem proibidos de usar um servidor de retransmissão.

Eles podem mudar para outro servidor ou executar o seu próprio e não perderão suas identidades digitais ou seguidores ao romper a plataforma de seu servidor anterior, pois ainda mantêm o controle de suas chaves privadas e os usuários podem usá-las em outro lugar para autenticar. quando os encontrarem.

Os servidores de retransmissão também podem executar o que quiserem: operar gratuitamente, cobrar uma pequena taxa para publicar ou baixar mensagens e até ter um NIP que exige prova de trabalho no estilo hash cash para enviar mensagens.

Eles podem ser um único servidor de retransmissão que hospeda postagens e as disponibiliza apenas para outros usuários ou um servidor que opera em escala, como Twitter ou Reddit (os clientes podem exibir e organizar as informações conforme desejado, o que permite simular qualquer mídia social). Tudo isso interopera perfeitamente, sem bloquear o acesso dos usuários.

Principais questões de gestão a serem abordadas pela Nostr

As chaves públicas/privadas do usuário são parte integrante de como o Nostr funciona como um protocolo. Isso atua como um vínculo estreito entre o usuário real e como os outros o identificam, evitando que qualquer servidor de retransmissão desvincule essas duas coisas, ou seja, forneça o identificador de alguém a outro usuário. Também resolve um dos maiores problemas da plataforma: a falta de controle sobre a própria identidade do usuário.

Mas isto também introduz novos problemas: a chave pode ser perdida, a chave pode ser comprometida e, se tal evento ocorrer, o usuário não poderá pedir ajuda.

Isto inevitavelmente exigirá um esquema para que os usuários mudem de um par de chaves para outro de uma forma verificável e detectável e para que possam interagir com outros usuários através do protocolo. Todo o protocolo se baseia em provar que um evento veio de um usuário específico (chave de identidade), portanto, uma vez comprometida a chave de alguém, todas essas garantias são lançadas ao ar.

Nostr requer um esquema criptográfico real que vincule a rotação de uma chave a outra. O desenvolvedor fiatjaf propôs uma solução básica que pode resolver este problema. A ideia básica é pegar uma longa lista de endereços derivados de uma única semente mestre e criar um conjunto de chaves “ajustadas”, semelhante a como as árvores Taproot são comprometidas com as chaves Bitcoin.

Taproot pega a raiz Merkle da árvore Taproot e a “adiciona” à chave pública para criar uma nova chave pública. Isso pode ser replicado adicionando a raiz Merkle à chave privada para obter uma chave privada que corresponda à nova chave pública. A ideia de Fiatjaf é encadear os compromissos de trás para frente, do fim ao início, para que cada chave ajustada realmente contenha a prova de que a próxima chave ajustada foi usada para criá-la.

Então, imagine começar pela chave Z, a última da cadeia. Você pode ajustá-lo com alguma coisa, depois voltar e criar uma versão ajustada da chave Y usando a chave ajustada Z (Z' + Y = Y'). A partir daqui, você pode pegar Y' e usá-lo para ajustar X (Y' + X = X'). Você faria isso até a chave A, pegaria A' e usaria essa chave a partir daí. Quando quebrado, o usuário pode transmitir um evento contendo a chave A não ajustada e a chave B' ajustada.

Isso conterá todos os dados necessários para mostrar que B' foi usado para gerar A', e o usuário pode parar imediatamente de seguir A' e seguir B'. Eles saberiam inequivocamente que B' é a próxima chave para aquele usuário e seguiriam essa chave.

No entanto, ainda existem alguns problemas com esta proposta. Primeiro, todas as chaves que serão usadas devem ser geradas antecipadamente e não há como alternar para um conjunto de chaves totalmente novo. Isso pode ser resolvido comprometendo-se uma chave mestra neste esquema que possa autenticar essa rotação ou simplesmente gerando um conjunto muito grande de chaves desde o início.

Qualquer um dos caminhos é viável, mas, em última análise, requer manter a chave raiz ou o material de codificação seguro e expor apenas teclas de atalho individuais (teclas de atalho) aos clientes Nostr.

No entanto, este esquema não protege os utilizadores nem fornece mecanismos para recuperação de identidade no caso de perda ou comprometimento do material de codificação de raiz.

Para alguma discussão sobre possíveis soluções aqui, outra maneira de pensar sobre isso é ajustar uma chave para uma chave mestra fria que também deve ser usada para assinar eventos de uma rotação de chave para outra. Você tem a chave A', que é derivada da adição de A e M (chave mestra); o evento de rotação será A, M e B' (gerado pela adição de B e M) e a assinatura de M. M pode ser uma chave de limite com múltiplas assinaturas – dois terços, três quintos, etc.

Isto pode adicionar redundância contra perdas e fornecer um mecanismo seguro para rotação de chaves. Isso também abre a porta para o uso de serviços para ajudar na recuperação ou para divulgar algumas dessas chaves para amigos de confiança. Oferece a mesma flexibilidade que o multisig no próprio Bitcoin.

PIN26 é também uma proposta que pode ser muito útil para lidar com este problema. Isto especifica uma extensão de protocolo para eventos que permite que uma assinatura de uma chave autorize outra chave a publicar eventos em seu nome. O “token” ou prova de assinatura delegada será então incluído em todos os eventos publicados pela segunda chave pública em nome da primeira. Pode até ser limitado no tempo, portanto os tokens de delegação expiram automaticamente e devem ser renovados.

A questão do gerenciamento de chaves e da segurança é um problema muito grande, com um espaço de design muito grande, cheio de compensações e pontos problemáticos. No entanto, se o Nostr não puder proteger e manter a integridade dessas identidades para os usuários, um protocolo baseado inteiramente em pares de chaves públicas/privadas usados ​​como identidades não será adotado em larga escala.

O novo ano das mídias sociais: princípios Nostr e questões-chave de gestão

Expansão voltada para Nostr

Todo o protocolo Nostr depende de alguém em algum lugar executando um servidor de retransmissão. Não existe “rede Nostr”, apenas relés e clientes conectados aos relés. As pessoas precisam ser incentivadas a operar retransmissores e, em última análise, isso será uma grande parte do quão longe os retransmissores poderão crescer no longo prazo. A menos que um retransmissor Nostr possa ser lucrativo ou pelo menos gerar dinheiro suficiente para cobrir seus próprios custos operacionais, nunca haverá um retransmissor do mesmo tamanho que o servidor do Twitter.

Publicitar

Dada a forma como o Nostr funciona como um protocolo, bloquear totalmente os anúncios seria trivial, tornando-o uma solução inviável. Os servidores de retransmissão podem tentar usar a publicidade como modelo de receita, que aparentemente é o principal modelo de receita para quase todos os serviços online gratuitos, mas o problema é que os usuários basicamente precisam aceitar. , mas os clientes também podem filtrar facilmente eventos de anúncio de sua UI se eles não tiverem sido criados pela chave pública que pretendiam assinar.

Micropagamento

Os micropagamentos são outra solução óbvia, especialmente dadas as tentativas contínuas de integrar o Relâmpago Network mais firmemente no aplicativo Nostr. Este modelo oferece muita flexibilidade na forma como você cobra. Os relés podem cobrar apenas pela postagem de eventos lá, pelo download da leitura de eventos ou por uma combinação dos dois, ajustando o preço de cada um com base em quantos recursos consomem. No entanto, é duvidoso que este modelo possa ser ampliado à escala do Twitter.

Os micropagamentos de conteúdo mostraram sua viabilidade em muitos produtos de nicho com base no Relâmpago Network, mas existem dois problemas fundamentais com a verdadeira expansão para uma escala global.

Primeiro, ainda não há adoção suficiente do Bitcoin. Mesmo que todos aceitassem magicamente pagar por cada pequena interação de serviço no Nostr, não haveria pessoas suficientes com bitcoins para apoiar algo tão massivo como o Twitter. Os Relays podem cobrar taxas de assinatura em moeda fiduciária, mas esses métodos de pagamento não suportam o pagamento de uma pequena taxa para cada evento publicado ou baixado.

Em segundo lugar, as pessoas estão realmente acostumadas com esse tipo de serviço gratuito. Isto é exatamente o que se esperaria. Não creio que os micropagamentos possam realmente suportar a retransmissão em grande escala.

O novo ano das mídias sociais: princípios Nostr e questões-chave de gestão

Existe uma maneira de tornar os micropagamentos “mais rígidos” ou mais sustentáveis ​​sem forçá-los a todas as classes de usuários que usam o retransmissor. Tem-se falado muito sobre a construção de vários aplicativos em cima do Nostr, exceto o clone do Twitter. GitHub, Wikipedia e até Uber.

O último é fundamental: as expectativas económicas. As pessoas estão muito acostumadas a pagar uma taxa quando um emprego é anunciado em algum lugar ou a pagar uma taxa a um operador de mercado quando encomendam algo on-line, mas não servem coisas que acham que deveriam ser gratuitas – Google, Twitter. Isso poderia fornecer uma maneira para os retransmissores criarem um pilar de renda sólido para seus usuários, sem criar muito atrito ou quebrar as expectativas do usuário potencial médio.

Se os micropagamentos também forem um fator, os operadores de retransmissão terão que executar um nó Lightning para receber fundos dos usuários primeiro. Isto poderia potencialmente aumentar a receita se tivesse uma sinergia adequada com qualquer modelo de micropagamento implementado pela retransmissão.

Quanto mais receita um servidor de retransmissão ganha, mais liquidez ele precisa na Lightning Network para facilitar isso. Se os operadores planearem correctamente a forma como implementam ou distribuem liquidez na rede, o simples acto de gerir um nó de encaminhamento poderá tornar-se um gerador de receitas significativo por si só, para além de quaisquer taxas cobradas pela recepção ou transmissão de dados através de retransmissores.

Conclusão

Projetos sociais da Web3, além dos já citados Nostr e Mastodonte, também incluem projetos como Farcaster e Lente, que não substituirá rapidamente as plataformas de mídia social existentes. Segundo as estatísticas, o Twitter tem centenas de milhões de usuários ativos, Facebook tem bilhões, mas Mastodonte tem apenas 2.5 milhões de usuários e Nostr tem apenas cerca de 220,000 identidades de usuários exclusivas. Muitos projetos sociais da Web3 enfrentam obstáculos de usabilidade que retardam a adoção em massa.

Mídia e política são inseparáveis. À medida que os projetos sociais da Web3 proliferam e a conversação pública se fragmenta em diferentes aplicações e protocolos, poderá haver resultados políticos. Até Messina, que há muito defende a descentralização dos meios de comunicação social, teme que a descentralização alimente ainda mais um discurso público que tem sido marcado pela hostilidade mútua e pela incompreensão nos últimos anos.

AVISO LEGAL: As informações neste site são fornecidas como comentários gerais do mercado e não constituem aconselhamento de investimento. Nós encorajamos você a fazer sua própria pesquisa antes de investir.

Junte-se a nós para acompanhar as novidades: https://linktr.ee/coincu

Harold

coincu Novidades

damus

Lightning Network

Mastodonte

Nostr

Twitter

Avatar de Haroldo

Autor

Harold

Com uma paixão por desvendar as complexidades do mundo financeiro, passei mais de quatro anos no jornalismo financeiro, cobrindo tudo, desde ações tradicionais até o que há de mais moderno em capital de risco. “Os mercados financeiros são um quebra-cabeça fascinante”, costumo dizer, “e adoro ajudar as pessoas a entendê-los”. É isso que me leva a levar um jornalismo financeiro claro e perspicaz aos leitores da Coincu.
Recursos Educacionais

O novo ano das mídias sociais: princípios Nostr e questões-chave de gestão

Novos designs de redes sociais sob a Quinta Direita têm sido explorados há anos, sem nenhum sinal de adoção em massa. No ano passado, com o desenvolvimento contínuo da tecnologia de criptografia e as preocupações com a aquisição do Twitter por Musk, a rede social descentralizada abriu novas oportunidades.
Os problemas que estas redes sociais estão a tentar resolver: podem incluir o reforço da censura, tornar a moderação de conteúdos mais flexível e reduzir o poder das grandes empresas de redes sociais para moldar e monitorizar o que as pessoas falam online, entre outras coisas.
À medida que novas plataformas surgem e crescem, a escolha de redes sociais alternativas muitas vezes envolve considerações políticas. Sites como Getr, Parler, Gab e Truth Social atendem à direita ao se promoverem como alternativas de liberdade de expressão ao Twitter.
O que vamos discutir hoje é Nostr-damus, um novo protocolo de mídia social que tem recebido muita atenção recentemente e é um tanto inovador. Estes incluem os princípios técnicos da Nostr, questões-chave de gestão a serem resolvidas e como incentivar o relé a continuar a operar.
O novo ano das mídias sociais: princípios Nostr e questões-chave de gestão

Visão geral do Nostr

Lançado em 2020, Nostr é um protocolo descentralizado que permite aos usuários possuir suas identidades e verificar postagens usando assinaturas digitais usando criptografia de chave pública-privada. Essas postagens são então propagadas para uma rede interconectada de servidores. O protocolo não usa blockchain, que foi considerado nos primeiros experimentos muito lento para redes sociais. Mas existem semelhanças estruturais, e Nostr encontrou um nicho inicial na multidão criptográfica com seu espírito libertário e de código aberto.

Mastodonte vs.

O protocolo Nostr e o primeiro servidor de retransmissão foram criados pelo desenvolvedor fiatjaf no final de 2020. Antes de ganhar ampla atenção, o Nostr era um protocolo de nicho silencioso com o objetivo de ser uma solução leve para os problemas do Twitter e do Mastodon.

Mastodon, uma rede de código aberto fundada em 2016, permite que qualquer pessoa configure um servidor. O design é frequentemente descrito como “federado” e pode ou não cair na linha confusa de “Web3”, dependendo de como isso é definido. O Mastodon permite que os usuários participem de comunidades selecionadas com regras personalizadas de moderação de conteúdo. Actualmente, o número de utilizadores registados atingiu mais de 200 milhões e tornou-se um porto seguro para liberais, jornalistas e académicos.

In Twitter e Mastodonte sistemas, identidades/nomes de usuário são controlados por quem executa o servidor.

A principal diferença no Nostr é que cada usuário usa um par de chaves pública/privada para lidar com a função, em vez de usar um nome de usuário de propriedade do operador do servidor, tornando o Nostr resistente à censura. Este é um dos principais blocos de construção para a construção de todo o protocolo Nostr.

O novo ano das mídias sociais: princípios Nostr e questões-chave de gestão

Evento: este é o tipo básico de objeto/dado usado pelos clientes e pelos servidores de retransmissão aos quais eles se conectam para enviar e recuperar mensagens. A ideia geral do protocolo é que os clientes enviem eventos para um servidor de retransmissão, que os armazena e indexa, e outros clientes podem se comunicar com o servidor de retransmissão para solicitar eventos que receberam e armazenaram. No original PIN 01, três tipos de eventos diferentes foram definidos:

  • Envie metadados sobre o usuário, como nome de usuário, foto, biografia, etc.
  • Envie SMS e conteúdo básico
  • Recomende o servidor de retransmissão para pessoas que seguem o criador do evento para se conectar

Todos os eventos são estruturados de uma forma especificamente definida. Inclui a chave pública do criador, o carimbo de data/hora da criação, o tipo (ou tipo na especificação), a carga útil do conteúdo e a assinatura do criador do evento. Alternativamente, pode haver tags que se referem a outros eventos ou usuários e possuem um valor de ID que é um hash de tudo, exceto a assinatura do criador (semelhante ao TXID de uma transação Bitcoin).

Isso permite que os usuários verifiquem a assinatura (e quem possui a chave, se ela não tiver sido comprometida) para garantir que a mensagem foi realmente criada pelo proprietário da chave pública nela contida e que a mensagem não foi alterada desde que eles assinaram isto.

Assim como uma transação Bitcoin não pode ser alterada depois de assinada sem invalidá-la, um usuário não pode alterá-la após o criador da transação. Nostr evento o assinou sem torná-lo uma fraude óbvia.

O sistema de tipo de evento foi expandido consideravelmente em relação ao original NIP. Existe um tipo de evento para mensagens criptografadas diretas que constroem um segredo compartilhado combinando a chave privada do remetente com a chave pública do destinatário, cujo resultado é o mesmo que você obtém combinando a chave pública do remetente com a chave privada do destinatário as chaves são iguais (é assim que funcionam o BIP 47 e os pagamentos silenciosos).

Existem também eventos substituíveis e tipos de eventos efêmeros. No caso de eventos substituíveis (obviamente), eles são projetados para que o criador original do evento possa assinar um novo evento para substituir o antigo. Os servidores de retransmissão que seguem esta especificação excluirão automaticamente eventos antigos de seu armazenamento e começarão a fornecer versões mais recentes aos clientes após o recebimento.

Eventos efêmeros são projetados de tal forma que, quando enviados a um retransmissor, serão transmitidos para qualquer pessoa assinante de seu criador, mas o servidor de retransmissão não deve armazená-los. Isso cria a possibilidade de que apenas quem está online veja a mensagem durante sua transmissão. Existe até um tipo de evento para representar reações aos eventos de outras pessoas (como curtidas ou emojis).

Falando na última pergunta, os eventos também podem conter tags. Atualmente, existem tipos de tags para o Evento (referindo-se a um evento Nostr exato), Chave pública (para marcar ou referir-se a outro usuário), e Assunto (para imitar a funcionalidade, como o assunto de um email).

O novo ano das mídias sociais: princípios Nostr e questões-chave de gestão

Tudo isso pode incluir ponteiros para servidores de retransmissão específicos dos quais os dados são buscados para que os usuários possam realmente interagir em servidores diferentes, ou seja, um usuário publica seu conteúdo em um servidor de retransmissão, conteúdo que pode ser interagido e referenciado por outro usuário em um servidor de retransmissão diferente. servidor de retransmissão para que qualquer usuário possa obter de forma coerente todo o thread de interação na ordem correta, sem ter que descobrir onde os dados relevantes estão em um grande número de operações complexas.

No original NIP, foi fornecida uma especificação de como um cliente interage com um servidor de retransmissão assinando uma estrutura de mensagens/dados que inclui filtros para quais eventos o cliente está interessado em receber. Esses filtros podem especificar a chave pública do usuário, o evento exato, o tipo de evento ou até mesmo um período de tempo específico que desejam com base em critérios anteriores.

Os usuários podem até enviar chaves públicas ou prefixos de IDs de eventos, como “1xjisj…” e receber qualquer um ou mais eventos de uma chave pública começando com essa sequência curta (isso é útil para ocultar dos servidores de retransmissão o que você realmente deseja ver) .

No geral, o protocolo é um esquema geral muito simples para passar mensagens entre usuários, cobrindo coisas importantes como garantir a integridade das mensagens e usar identidades de chave pública para enviar mensagens, ao mesmo tempo que facilita que os servidores de retransmissão da infraestrutura final possam ser altamente centralizados ou permitir que os usuários executem seus próprios servidores de retransmissão pessoais, interagindo perfeitamente entre si e sem causar caos massivo no caso de os usuários serem proibidos de usar um servidor de retransmissão.

Eles podem mudar para outro servidor ou executar o seu próprio e não perderão suas identidades digitais ou seguidores ao romper a plataforma de seu servidor anterior, pois ainda mantêm o controle de suas chaves privadas e os usuários podem usá-las em outro lugar para autenticar. quando os encontrarem.

Os servidores de retransmissão também podem executar o que quiserem: operar gratuitamente, cobrar uma pequena taxa para publicar ou baixar mensagens e até ter um NIP que exige prova de trabalho no estilo hash cash para enviar mensagens.

Eles podem ser um único servidor de retransmissão que hospeda postagens e as disponibiliza apenas para outros usuários ou um servidor que opera em escala, como Twitter ou Reddit (os clientes podem exibir e organizar as informações conforme desejado, o que permite simular qualquer mídia social). Tudo isso interopera perfeitamente, sem bloquear o acesso dos usuários.

Principais questões de gestão a serem abordadas pela Nostr

As chaves públicas/privadas do usuário são parte integrante de como o Nostr funciona como um protocolo. Isso atua como um vínculo estreito entre o usuário real e como os outros o identificam, evitando que qualquer servidor de retransmissão desvincule essas duas coisas, ou seja, forneça o identificador de alguém a outro usuário. Também resolve um dos maiores problemas da plataforma: a falta de controle sobre a própria identidade do usuário.

Mas isto também introduz novos problemas: a chave pode ser perdida, a chave pode ser comprometida e, se tal evento ocorrer, o usuário não poderá pedir ajuda.

Isto inevitavelmente exigirá um esquema para que os usuários mudem de um par de chaves para outro de uma forma verificável e detectável e para que possam interagir com outros usuários através do protocolo. Todo o protocolo se baseia em provar que um evento veio de um usuário específico (chave de identidade), portanto, uma vez comprometida a chave de alguém, todas essas garantias são lançadas ao ar.

Nostr requer um esquema criptográfico real que vincule a rotação de uma chave a outra. O desenvolvedor fiatjaf propôs uma solução básica que pode resolver este problema. A ideia básica é pegar uma longa lista de endereços derivados de uma única semente mestre e criar um conjunto de chaves “ajustadas”, semelhante a como as árvores Taproot são comprometidas com as chaves Bitcoin.

Taproot pega a raiz Merkle da árvore Taproot e a “adiciona” à chave pública para criar uma nova chave pública. Isso pode ser replicado adicionando a raiz Merkle à chave privada para obter uma chave privada que corresponda à nova chave pública. A ideia de Fiatjaf é encadear os compromissos de trás para frente, do fim ao início, para que cada chave ajustada realmente contenha a prova de que a próxima chave ajustada foi usada para criá-la.

Então, imagine começar pela chave Z, a última da cadeia. Você pode ajustá-lo com alguma coisa, depois voltar e criar uma versão ajustada da chave Y usando a chave ajustada Z (Z' + Y = Y'). A partir daqui, você pode pegar Y' e usá-lo para ajustar X (Y' + X = X'). Você faria isso até a chave A, pegaria A' e usaria essa chave a partir daí. Quando quebrado, o usuário pode transmitir um evento contendo a chave A não ajustada e a chave B' ajustada.

Isso conterá todos os dados necessários para mostrar que B' foi usado para gerar A', e o usuário pode parar imediatamente de seguir A' e seguir B'. Eles saberiam inequivocamente que B' é a próxima chave para aquele usuário e seguiriam essa chave.

No entanto, ainda existem alguns problemas com esta proposta. Primeiro, todas as chaves que serão usadas devem ser geradas antecipadamente e não há como alternar para um conjunto de chaves totalmente novo. Isso pode ser resolvido comprometendo-se uma chave mestra neste esquema que possa autenticar essa rotação ou simplesmente gerando um conjunto muito grande de chaves desde o início.

Qualquer um dos caminhos é viável, mas, em última análise, requer manter a chave raiz ou o material de codificação seguro e expor apenas teclas de atalho individuais (teclas de atalho) aos clientes Nostr.

No entanto, este esquema não protege os utilizadores nem fornece mecanismos para recuperação de identidade no caso de perda ou comprometimento do material de codificação de raiz.

Para alguma discussão sobre possíveis soluções aqui, outra maneira de pensar sobre isso é ajustar uma chave para uma chave mestra fria que também deve ser usada para assinar eventos de uma rotação de chave para outra. Você tem a chave A', que é derivada da adição de A e M (chave mestra); o evento de rotação será A, M e B' (gerado pela adição de B e M) e a assinatura de M. M pode ser uma chave de limite com múltiplas assinaturas – dois terços, três quintos, etc.

Isto pode adicionar redundância contra perdas e fornecer um mecanismo seguro para rotação de chaves. Isso também abre a porta para o uso de serviços para ajudar na recuperação ou para divulgar algumas dessas chaves para amigos de confiança. Oferece a mesma flexibilidade que o multisig no próprio Bitcoin.

PIN26 é também uma proposta que pode ser muito útil para lidar com este problema. Isto especifica uma extensão de protocolo para eventos que permite que uma assinatura de uma chave autorize outra chave a publicar eventos em seu nome. O “token” ou prova de assinatura delegada será então incluído em todos os eventos publicados pela segunda chave pública em nome da primeira. Pode até ser limitado no tempo, portanto os tokens de delegação expiram automaticamente e devem ser renovados.

A questão do gerenciamento de chaves e da segurança é um problema muito grande, com um espaço de design muito grande, cheio de compensações e pontos problemáticos. No entanto, se o Nostr não puder proteger e manter a integridade dessas identidades para os usuários, um protocolo baseado inteiramente em pares de chaves públicas/privadas usados ​​como identidades não será adotado em larga escala.

O novo ano das mídias sociais: princípios Nostr e questões-chave de gestão

Expansão voltada para Nostr

Todo o protocolo Nostr depende de alguém em algum lugar executando um servidor de retransmissão. Não existe “rede Nostr”, apenas relés e clientes conectados aos relés. As pessoas precisam ser incentivadas a operar retransmissores e, em última análise, isso será uma grande parte do quão longe os retransmissores poderão crescer no longo prazo. A menos que um retransmissor Nostr possa ser lucrativo ou pelo menos gerar dinheiro suficiente para cobrir seus próprios custos operacionais, nunca haverá um retransmissor do mesmo tamanho que o servidor do Twitter.

Publicitar

Dada a forma como o Nostr funciona como um protocolo, bloquear totalmente os anúncios seria trivial, tornando-o uma solução inviável. Os servidores de retransmissão podem tentar usar a publicidade como modelo de receita, que aparentemente é o principal modelo de receita para quase todos os serviços online gratuitos, mas o problema é que os usuários basicamente precisam aceitar. , mas os clientes também podem filtrar facilmente eventos de anúncio de sua UI se eles não tiverem sido criados pela chave pública que pretendiam assinar.

Micropagamento

Os micropagamentos são outra solução óbvia, especialmente dadas as tentativas contínuas de integrar o Relâmpago Network mais firmemente no aplicativo Nostr. Este modelo oferece muita flexibilidade na forma como você cobra. Os relés podem cobrar apenas pela postagem de eventos lá, pelo download da leitura de eventos ou por uma combinação dos dois, ajustando o preço de cada um com base em quantos recursos consomem. No entanto, é duvidoso que este modelo possa ser ampliado à escala do Twitter.

Os micropagamentos de conteúdo mostraram sua viabilidade em muitos produtos de nicho com base no Relâmpago Network, mas existem dois problemas fundamentais com a verdadeira expansão para uma escala global.

Primeiro, ainda não há adoção suficiente do Bitcoin. Mesmo que todos aceitassem magicamente pagar por cada pequena interação de serviço no Nostr, não haveria pessoas suficientes com bitcoins para apoiar algo tão massivo como o Twitter. Os Relays podem cobrar taxas de assinatura em moeda fiduciária, mas esses métodos de pagamento não suportam o pagamento de uma pequena taxa para cada evento publicado ou baixado.

Em segundo lugar, as pessoas estão realmente acostumadas com esse tipo de serviço gratuito. Isto é exatamente o que se esperaria. Não creio que os micropagamentos possam realmente suportar a retransmissão em grande escala.

O novo ano das mídias sociais: princípios Nostr e questões-chave de gestão

Existe uma maneira de tornar os micropagamentos “mais rígidos” ou mais sustentáveis ​​sem forçá-los a todas as classes de usuários que usam o retransmissor. Tem-se falado muito sobre a construção de vários aplicativos em cima do Nostr, exceto o clone do Twitter. GitHub, Wikipedia e até Uber.

O último é fundamental: as expectativas económicas. As pessoas estão muito acostumadas a pagar uma taxa quando um emprego é anunciado em algum lugar ou a pagar uma taxa a um operador de mercado quando encomendam algo on-line, mas não servem coisas que acham que deveriam ser gratuitas – Google, Twitter. Isso poderia fornecer uma maneira para os retransmissores criarem um pilar de renda sólido para seus usuários, sem criar muito atrito ou quebrar as expectativas do usuário potencial médio.

Se os micropagamentos também forem um fator, os operadores de retransmissão terão que executar um nó Lightning para receber fundos dos usuários primeiro. Isto poderia potencialmente aumentar a receita se tivesse uma sinergia adequada com qualquer modelo de micropagamento implementado pela retransmissão.

Quanto mais receita um servidor de retransmissão ganha, mais liquidez ele precisa na Lightning Network para facilitar isso. Se os operadores planearem correctamente a forma como implementam ou distribuem liquidez na rede, o simples acto de gerir um nó de encaminhamento poderá tornar-se um gerador de receitas significativo por si só, para além de quaisquer taxas cobradas pela recepção ou transmissão de dados através de retransmissores.

Conclusão

Projetos sociais da Web3, além dos já citados Nostr e Mastodonte, também incluem projetos como Farcaster e Lente, que não substituirá rapidamente as plataformas de mídia social existentes. Segundo as estatísticas, o Twitter tem centenas de milhões de usuários ativos, Facebook tem bilhões, mas Mastodonte tem apenas 2.5 milhões de usuários e Nostr tem apenas cerca de 220,000 identidades de usuários exclusivas. Muitos projetos sociais da Web3 enfrentam obstáculos de usabilidade que retardam a adoção em massa.

Mídia e política são inseparáveis. À medida que os projetos sociais da Web3 proliferam e a conversação pública se fragmenta em diferentes aplicações e protocolos, poderá haver resultados políticos. Até Messina, que há muito defende a descentralização dos meios de comunicação social, teme que a descentralização alimente ainda mais um discurso público que tem sido marcado pela hostilidade mútua e pela incompreensão nos últimos anos.

AVISO LEGAL: As informações neste site são fornecidas como comentários gerais do mercado e não constituem aconselhamento de investimento. Nós encorajamos você a fazer sua própria pesquisa antes de investir.

Junte-se a nós para acompanhar as novidades: https://linktr.ee/coincu

Harold

coincu Novidades

Visitado 61 vezes, 1 visita(s) hoje