Replies (18)

Basicamente, o que acontece é que quando você edita um evento, na verdade você não está editando um evento e sim publicando outro que faz referência. É isso, o nip 37.
Essa ideia de NIP(nostr improviment proposal) veio dos BIPs(bitcoin improviment proposal) do bitcoin, a ideia é que a base do protocolo seja bem enxuta e esses 'improviments' sejam funções adicionais, que podem ou não ser opcionais, para algo além da base, eles atuam como algo extra ou uma substituição/melhoramento de algo já existente. Geralmente se discute esse tipo de coisa pela questão de implantação mesmo, o #Amethyst é o único cliente que uso que tem suporte a edição de posts, esse tipo de coisa gera uma "quebra" na rede, além de outras inconveniências e/ou problemas +ou- graves. Isso é apenas uma ideia da coisa, algo para se localizar, não cabe a mim detalhar isso certinho
Eu fui ler agora o link que @Dante postou. É pior do que isso. Não é só o conteúdo que pode ser editado e sim o próprio evento. Se for isso, então, é um problemão. Tradução: 1. O evento inteiro é editável, não apenas o conteúdo. Então, uma resposta pode ser movida do thread A para o thread B, o que quebraria todas as respostas sob ele. Então, os usuários podem ser levados para tópicos separados pelo proprietário da resposta anterior. O tópico separado pode significar o oposto do tópico atual. As respostas também podem "roubar" respostas para si mesmas, em tópicos separados. Os respondentes também podem "roubar" respostas para si mesmos, em postagens separadas, ajudando a construir seu WoT. 2. Não está claro como interagir com kind1. Kind 1 pode ser uma resposta para um kind 31000? Muitos problemas surgem quando você mistura os dois. 3. Não há histórico de edição. O que é muito importante para os usuários.
O NIP é uma especificação técnica, uma nova possibilidade que pode compor o nostr. Como o protocolo é descentralizado, você não pode mudar a estrutura essencial das NIPs anteriores que já estão em uso, então cada NIP representa uma adição geralmente retrocompativel com protocolo. O que o fiatjaf está propondo é um evento igual ao tipo 1, mas que pode ser substituído, assim como ocorre com o evento de user status.
Dá uma olhada nas respostas, você vai aprender algo bastante útil, até porque os nips limitam o uso de contas de um client para outo...