Oddbean new post about login | logout Minha tristeza atual com o Nostr é o pessoal responder aos meus posts e aparecer num client ou em outro. No momento estou utilizando 3 clients diferentes. Por algum motivo do além, só encontrei uma resposta do @idsera no Amethyst, pq nem Primal e nem Nostrudel mostraram. E nem é uma resposta antiga. Se alguém tiver uma luz, comenta aí plz.
Are you using the same relays? Do you tried (just testing) to set only one and the same across all the others? Which clients are you using?
Relays. Sempre relays.
Sempre! É o ponto forte e o calcanhar de aquiles do Nostr como base pra uma rede social.
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í.
Olha só: os mesmos relays, clientes distintos https://m.primal.net/KutV.png https://m.primal.net/Kutd.png
só uma curiosidade: o Nostrudel minera minhas novas mensagens, mas não parece fazer o mesmo para as respostas. todas as minhas mensagens são mineradas com dificuldade 21.
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)
Até onde eu sei, ninguem implementa nip-13 direitinho. todo mundo implementa bugado.
isso quando implementam né. a galera não entende que só de implementar direito já vai atrapalhar o trampo do reply guy.
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á).
o amethyst usa relays de forma inteligente, buscando coisas nos relays das pessoas que te respondem caso não achem nos seus. Tambem usa relays diferentes para coisas diferentes (ele tem 3 configurações de relays, se não me engano). Outros clientes que usam relays de forma "burra" podem não achar tudo que ele acha
Eu estava olhando e temos pelo menos 3 relays em comum: wss://nos.lol/ wss://relay.damus.io/ wss://relay.primal.net/ Tanto o Amethyst, Nostrudel e Primal meus tem esses três relays, assim como a conta do @idsera tem esses três relays cadastrados também. A última mensagem dele eu vi no primal, mas tive que ir buscar o link do blog no amethyst, pq nem primal nem nostrudel estão mostrando. 'Teoricamente' era para funcionar.
Eu testo muito clientes também, os únicos que não tive problemas com sumiço de notificação foi de fato o nostr:nprofile1qqs24yz8xftq8kkdf7q5yzf4v7tn2ek78v0zp2y427mj3sa7f34ggjcpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcppemhxue69uhkummn9ekx7mp0qyg8wumn8ghj7mn0wd68ytnddakj703s8dt e no PC o nostter.app.
hmmm, acho que não... eu tenho usado pelo menos 3 relays grandes em comum, e as mensagens estão sendo aceitas. É estranho pq se a pessoa vê e responde, é pq baixou a mensagem de pelo menos um relay em comum. O problema é que as respostas não aparecem pra mim em um ou outro cliente (todos com os mesmos relays)
