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.
Discussion
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:
- Tiktok
- 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.