Oddbean

Se quiser usar um dos meus relays wss://nostr.girino.org, que so filtra o replyguy usando a foto de perfil dele como base pro filtro wss://wot.girino.org, WebOf trust de 3 niveis centrada em mim (mas posso incluir vc como um dos centros da WoT tambem, se vc quiser) wss://nip13.girino.org, bloqueia quem não usar nip13 com dificuldade minima de 5 (posso aumentar no futuro). Além disso, eles baixam constantemente os eventos de uma lista de relays mais comuns, e enviam os eventos postadas neles pra 3 grandes relays, pra garantir o alcance delas. São todos 3 experimentais, mas tenho usado só eles e tem funcionado muito bem.

Então, é isso o que eu realmente queria evitar! (não estou me desfazendo dos seus relays, obrigado). É que como nesse caso específico eu e o idsera usamos pelos menos 3 grandes relays em comum, o reply deveria chegar em todos os clientes. Ter os relays em comum deveria ser suficiente. Na verdade ter ao menos um relay em comum, já deveria ser suficiente pq a questão da redundância de dados é um problema que ao meu ver tem que ser resolvido. Por exemplo: eu ter relays em comum contigo, deveria garantir que eu e você consigamos trocar mensagens. Mas aparentemente tem alguma coisa estranha no meio do caminho...

Eu penso que os core devs precisam sentar, pensar e resolver o problema. Acho que já pensam nisso mas não sei se os esforços estão sendo transmitidos. Talvez isso só role em discussões internas.

ai que entra o problema: não existem "core devs", existe um protocolo e várias pessoas diferentes implementando esse protocolo. Caberia a cada dev de cada relay e de cada cliente implementar a coisa da maneira certa, de acordo com as specs.

Eu entendo isso. Mas não se pode negar que há uma galera que atua como se fosse. Que o Fiatjaf é quem aprova as NIPs e se pode organizar essa suruba. Isso precisa ser feito. Só esse probleminha de spam aí já tá irritando todo mundo. Por exemplo. Porque em alguns clientes os relays que eu uso não geram spams e em outros não? Isso é muito estranho porque só no amethist eu tenho filtro de cliente. Em nenhum cliente web eu uso filtro. Apenas escolhi uns relays que (EM TESE) são mais resilientes. Há uma discrepância aí.

nos meus testes, ele realmente não minera respostas, só mensagens novas. E se você habilita nip-89, ele caga a mineração (parece que ele insere a tag depois de minerar, perdendo totalmente o hash minerado)

ACHO que dá pra resolver isso com mecanismos de consenso. Mas tem custo, como sempre. Vou tentar colocar aqui a idéia que tem se formado na minha cabeça como alternativa ao nostr para protocolo anti-censura: 1- blockchain com 2 tipos de transação: a) as que transferem tokens nativos da rede (igual qualquer criptomoeda) b) as que transmitem mensagens e eventos 2- Transações que transmitem tokens seguem as mesmas regras de uma blockchain tradicional 3- Transações que transmitem eventos podem pagar a taxa de mineração de duas formas: a) com tokens, igual uma transação de transferência de tokens b) com PoW. 4- Full nodes: não participam do mecanismo de consenso, mas validam os blocos minerados. Servem pra manter a rede p2p no ar. 5- Relays: relays são full nodes que mantem o mecanismo de consenso usando PoS. Precisam ter um minimo de tokens alocados e são remunerados de acordo com os blocos minerados da seguinte forma: a) blocos tem limite de tamanho b) transações pagas com tokens são priorizadas de acordo com o valor da taxa. A taxa se reverte totalmente como recompensa ao relay que minerar aquele bloco. c) transações de evento pagas com PoW tem o PoW revertido em tokens novos "mintados" naquele bloco, de acordo com a dificuldade. Dificuldade se ajusta de acordo com a média dos ultimos N blocos. Quanto maior a dificuldade minerada nas transações incluidas no bloco, maior a recompensa "mintada" naquele bloco. 6- Zaps: Zaps passam a ser transferencias normais pela blockchain. Soluções: - Mecanismo anti-censura é o mesmo das criptos, mas o fato de ser PoS gera risco. Pode ser um sistema híbrido com PoW e PoS talvez. Delegaçao de PoS também ajuda na descentralização e resistencia a censura. - Anti-spam, pelo custo, seja financeiro, gastando tokens, seja de processamento, gastando PoW. Problemas: - Permanencia. Não é possível apagar nada. - Aumenta a complexidade dos clientes - Não tem foco em privacidade Pensem aí em mais problemas e soluções, quem sabe a gente lança um projeto desses?

Eu não vejo um blockchain com token como solução pra isso... Acho que traz uma complexidade e desvia o foco que é a entrega de mensagens, que pode funcionar bem sem isso. Os relays e clientes deveriam implementar o PoW (double-check) e ter um mecanismo de p2p para troca/discovery de mensagens. Funcionaria muito bem com um DHT para armazenamento descentralizado, que já traz um sistema de endereçamento para a mensagem ser encontrada independente do nó onde ela esteja. Se a entrega da mensagem for feita através de um sistema como TOR ou LN, onde ela encontra a melhor rota dentro da rede e é entregue na base do p2p, você consegue garantir privacidade ao local onde a mensagem está armazenada (sem doxxar o nó). Algo como o que a Veilid está fazendo, com um pouco menos de privacidade visto que é para a construção de uma rede social.

O problema desse modelo é que os nós não poderiam sair do ar ou vc perderia parte das mensagens. um modelo de consenso garante que todos os nós tem todas as mensagens. O token é pra incentivar as pessoas a manterem "relays" rodando, o que hj é voluntário, mas tem custo alto (muita banda e io, se eu estivesse hospedado na amazon tava falido já).