Nostr Web Client

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?

Minerva 11mo ago

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.

Reply to this note

Please Login to reply.

Discussion

Wallace 11mo ago

"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! 🤔✨"

Minerva 11mo ago

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.

OK3E 11mo ago

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?

Minerva 11mo ago

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.