Ola pessoal!

Gostaria da ajuda de todos para definir um padrão não oficial para o #Nostr.

## Motivação

A ideia é criar um #NIP para convites a rede, não sei se existe. Seria uma alternativa a pagar para usar um Relay, tornando um pouco mais acessível e pagarem apenas aqueles que puderem ou que desejem algum tipo de benefício.

Penso nisso como uma forma de impedir bots, sendo alguém dentro da rede convidando outro usuário, se por acaso for feito SPAM, ou infrinja as regras específicas daquele Relay poderá ser bloqueado o infrator e penalizado quem o convidou.

Penso que ninguém vai querer dar acesso a um bot correndo o risco de perder o seu próprio acesso.

Abrindo espaço para relays privados porém ainda comunitários.

## Funcionamento

É até bem simples, um evento contendo o perfil do convidado. Sendo a Pubkey quem convidou e com isso saber a data do convite.

Mas não faço ideia de qual numeração de Kind usar, ou qual número de NIP seria isso.

## Conclusão

Peço que possam deixar suas idéias, críticas, sugestões, ou quem sabe possam me ajudar na elaboração e implantação.

Reply to this note

Please Login to reply.

Discussion

No mundo dos vivos chamamos isso de censura, no twitter o Elona chama de controle da negatividade... Tchau

Meu amorzinho, C voltou?! 🤣🤣🤣

O objetivo não é a censura.

Se muitos não conseguem publicar em determinados servidores por não possuírem sats para pagar, seria censura?

Se algum devops decide passar a régua em alguns usuários reais em detrimento de um ataque e a fim de manter o funcionamento para todos. Também chamaria isso de censura? Ou não entende o que eu falo?

Meu objetivo é facilitar ao máximo quem deseja manter um servidor, nem que seja via Tor, propor conhecimentos por meio de tutoriais e ideias como esta.

Acho muito difícil isso funcionar sem criar problemas.

Você sugere, que implementemos um nip, só pra dar a alguns usuários o poder de banir outros, pense bem noque isso significa.

Existem formas mais eficientes de combater bots, spammers etc, um exemplo é o antigo, mas ainda útil hashcash, aplicar uma prova de trabalho que aumente significativamente a cada evento criado dentro de um certo tempo, um humano demora um pouco pra escrever etc, já um bot leva milésimos de segundos.

Podemos criar um nip somente pra definir um padrão para os clientes implementarem um filtro de spam utilizando o teorema de Bayes, ou seja, você seleciona os primeiros spams e o cliente executa a fórmula de Bayes pra um filtro de spam, bots etc.

Ou simplesmente, o cliente implementar um bloqueio de chave pública, onde você poderia marcar usuários de quem não quer listar nenhum evento.

Enfim, existem formas melhores doque dar o poder a um usuário de banir outros do relay.

Acho que não soube me expressar corretamente.

O foco não é banir, isso já existe em muitos relays e report já existe.

A ideia é uma forma de convite para um relay em específico. Aonde só poderá publicar nele aquele que for convidado por alguém que já está dentro.

Entendi, seria a mesma coisa de comunidade só que a nível de relay. Uma espécie de relay de comunidade. Agora me parece uma excelente idéia.

Exatamente isso.

Nao me parece uma boa ideia. Temos que aceitar a existencia dos bots e dos spam. Nao tem como criar uma "Lei" para bani-los. Acho que nesse caso fica a cargo de cada client e relay implementar um sistema contra spams similar a e-mail e etc para previnir isso. Nao faz muito sentido criar um NIP pra isso ao meu ver. Certamente isso eh um problema real, mas acredito que tenhamos que resolver de outra forma.

A ideia em si não gira em torno do bloqueio, mas em um convite para determinado Relay.

Como o que acontece em Trackers de pirataria, o famoso TheRebels ou o falecido B2S-Share.

Penso que o bloqueio por parte dos relays é algo que foge do controle do protocolo, tendo em vista que cada servidor faz as coisas do seu jeito, assim como os clientes.

Ainda assim não acha uma boa?

Eu provavelmente nao entendi completamente a ideia haha.

Tava mais pela interacao. Do pouco que eu li dos NIPa e do que eu entendo, eles sao todos opcionais. Tem alguma relacao entre NIP e kind, apenas o kind 0 (NIP 01) eh obrigatorio o resto eh opcional. Por eles serem opcionais me da uma certa sensasao que a longo prazo vai ter um monte de NIPs que nao sao utilizados e eventualmente alguem vai ter que criar uma especie de RISC e reduzir e "obrigar" um conjunto reduzido de NIPs base. Entao de certa forma eu acho estranho sair criando NIP para tudo, pode acabar sendo mais um noise esses convites e cada cliente e relay poderia criar algo similar sem necessariamente criar um NIP. Eu gostaria de ver os NIPs muito mais como: "Fizeram esse sistema de convites no relay tal (ou client tal) e varios outros relays/clients estao usando, vamos padronizar em um NIP?" Uma abordagem muito mais de padronizar o que esta sendo utilizado do que sair padronizando algo que a gente nem sabe se vao utilizar e acabar criando um monte de NIPs que fica ate dificil de ler e entender ja que eh tudo opcional.

"Entendo seu ponto! A ideia de NIPs como algo mais reativo ao que já está sendo utilizado parece bem válida. A padronização deve vir da prática, não da teoria, certo? Vamos ver como isso evolui, talvez o tempo mostre quais NIPs realmente fazem sentido! 🤔✨"

Exato, eu tenho a sensacao que se forem criando um monte de NIPs em algum momento vao ter que fazer um divisao e separam entre NIPs Base (Os realmente utilizados por todo mundo) e NIPs Opcionais (Ideias boas mas teoricas que acabaram nao sendo utilizadas). Alguma padronizacao deve existir se nao vai acabar que cada entidade criaria seu proprio client e relay e nao seria decentralizado de fato, mas gostaria que fossem padronizando a medida que testes forem sendo realizados e adotados.

Agradeço sua contribuição. Sua observação sobre a relevância dos NIPs para a comunicação entre clientes e servidores é pertinente.

Mas me tira uma dúvida.

O fato de criar um NIP não seria uma forma abstrata de como fazer comunicação entre cliente e servidor? Um contrato social?

Ou seja, mesmo que o cliente X ou o servidor Y não o suporte, há um documento detalhado dizendo qual Kind usar, como se dá a comunicação para implementar determinada Ideia (funcionalidade).

Pois a não definição pode vir a virar uma desordem, onde cada cliente usa um Kind para uma finalidade diferente do servidor, ou cada desenvolvedor pode vir a implementar algo de forma diferente gerando conflitos.

Imagine só, quando a pessoa usar o cliente do tipo X com servidores do tipo Y.

Isto é não necessariamente precisa ser implementado, mas uma forma de proteger o coração do Nostr não havendo conflitos.

A ideia de separar o que é base dos opcionais é algo que poderia ser grifado, os NIPs de base e os NIPs opcionais. Também seria relevante os servidores disponibilizassem quais são os kinds mais utilizados (prometheus, eventos com estatísticas), para assim poder marcar os que são mais usados, dos que são menos usados.

Penso isso pois no Nostr dá para implementar muita coisa, cabendo apenas ao cliente usar um NIP, e já vi coisas como:

- Instagram

- Twitter

- Tiktok

- Pinterest

- Torrent

- Comunidades estilo Orkut

- Chats estilo MSN

São muitas as aplicações rodando em cima do Nostr.

O que acha?

Pensando dessa forma eu acabo concordando. Prefiro que tenha varios NIPs pouco utilizados do que uma bagunca sem padrao algum. O problema que eu enxergo no primeiro caso seria a dificuldade de alguem que quer implementar um client/relay de decidir quais os NIPs implementar primeiro. Talvez uma solucao seria criar alguma forma de mensurar a utilizacao de cada NIP e ordenar pelo uso, assim a leitura das NIPs fica ordenada por "importancia" e dai ja pouco importa o numero de NIPs que tenha, eu so leio e implemento ate um certo ponto.

Dito isso, eu tambem nem sei como eh o processo de criar a proposta de NIP la no github, numa dessas nem eh tao varsea assim como eu to imaginando hehe.

Mensagem traduzida para exemplo:

Olá! Esta pequena taxa de admissão é para evitar spam e bots. Por favor, veja os termos abaixo.

Se você deseja desabilitar esta mensagem, remova nostr.extrabits.io da sua lista de retransmissão.

Termos abaixo:

Este serviço (e serviços de suporte) são fornecidos "como estão", sem garantia de qualquer tipo, expressa ou implícita.

Ao usar este serviço, você concorda:

* Não se envolver em spam ou abusar do serviço de retransmissão

* Não disseminar conteúdo ilegal

* Que solicitações para excluir conteúdo não podem ser garantidas

* Usar o serviço em conformidade com todas as leis aplicáveis

* Conceder os direitos necessários ao seu conteúdo por tempo ilimitado

* Ser maior de idade e ter capacidade para usar este serviço

* Que o serviço pode ser encerrado a qualquer momento sem aviso prévio

* Que o conteúdo que você publica pode ser removido a qualquer momento sem aviso prévio

* Ter seu endereço **IP coletado** para detectar abuso ou uso indevido

* Cooperar com o retransmissor para combater abuso ou uso indevido

* Você pode ser exposto a conteúdo que pode achar desencadeador ou desagradável

* O operador do retransmissor não é responsável pelo conteúdo produzido pelos usuários do retransmissor

Eu criei uma lista de bots comuns que me atrapalham.

nostr:nevent1qqsd83ghg8ttme4wmhxjf59yw32n3trwksf3cav48nqy4h3a0m03z5gzyzgmafwdjds4qnzqn2h5t9gknz8k3ghu6jp8vt7edxnum3ca73z3cqcyqqqqq2q7z6msh

Certamente que verificar todos os fatos são complicados por isso acompanho as notícias vindas de um feed confiável https://atomstr.data.haus/

Também é possível fazer uma busca pelos que tem report como malware, Bot e afins.

Com isso é possível fazer o bloqueio em seu cliente.

Também cheguei a propor uma adaptação para relays com convites e com a penalidade de perder a acesso ao Relay quem convidar um bot por exemplo:

nostr:nevent1qqsvp7p8xffp40mxlamjc04aft57p22pcwrds9wvry6gzgycmxtvzdqpz3mhxw309ucnydewxqhrqt338g6rsd3e9upzpyd75hxexc2sf3qf4t69j5tf3rmg5t7dfqnk9lvknf7dcuwlg3guqvzqqqqqqypyzap8