NIP-39 adiciona Bluesky e Discord enquanto NIP-51 move listas favoritas

NIP-39 recebe uma frase de prova e dois provedores

O NIP-39 define como associar uma chave pública Nostr a uma identidade em outra plataforma. As associações ficam em tags i dentro de um evento kind 10011. Cada tag traz o provedor e a identidade no primeiro valor, seguidos por um ponteiro para a evidência publicada no provedor.

A mudança integrada adiciona uma frase recomendada para todos os provedores:

Verifying that I control the following Nostr public key: <npub encoded public key>

Antes, as seções de GitHub, Twitter, Mastodon e Telegram descreviam textos diferentes. Havia diferenças de pontuação e aspas. Agora as quatro apontam para a mesma frase.

A nova regra tolera evidências antigas. Um verificador SHOULD aceitar qualquer prova publicada pela identidade declarada quando ela contiver o npub do usuário. A especificação usa SHOULD, não MUST, tanto para a frase quanto para a regra de compatibilidade. Isso orienta clientes sem tornar uma frase exata a única evidência válida.

A mesma integração acrescenta dois tipos de declaração:

• bluesky usa um handle sem o @ inicial como identidade. A prova é a record key de um post do Bluesky. O caminho definido é bsky.app/profile/<identity>/post/<proof>.
• discord usa um nome de usuário do Discord. A prova contém os identificadores de guild, channel e message nessa ordem. O caminho definido é discord.com/channels/<proof>.

A seção do Discord registra um limite explícito. Uma mensagem só pode ser lida por quem tem acesso ao servidor onde foi publicada. Um cliente sem esse acesso não pode verificar a declaração. Uma tag i bem formada não prova, por si só, que o proprietário da chave controla a conta vinculada.

NIP-51 move listas favoritas para o kind 10021

A outra integração altera duas linhas do registro. O NIP-51 atribuía o kind 10011 a uma lista padrão de follow sets favoritos. Cada tag a nesse evento aponta para um follow set de kind 30000.

O kind 10011 também já era usado pelo NIP-39 para declarações de identidade. Um evento substituível normal tem apenas um valor atual para cada autor e kind. Colocar dois modelos de dados sem relação no mesmo kind impede que um cliente determine o significado apenas pelo número.

O PR #2417 muda a linha do NIP-51 para o kind 10021 e adiciona 10021 à tabela de kinds. Ele não altera os follow sets de kind 30000, seus identificadores d nem as tags a que apontam para eles. A mudança afeta apenas a lista padrão que registra quais conjuntos o usuário marcou como favoritos.

O texto integrado não define um evento de migração nem um procedimento de conversão para listas já publicadas como kind 10011. Implementações que seguiram o rascunho anterior precisam reconhecer que esses dados podem existir e não devem interpretar todo evento kind 10011 como lista favorita. No texto atual do NIP-51, novas listas favoritas pertencem ao kind 10021.

O que mudou e o que não mudou

NIP-39 e NIP-51 continuam marcados como draft e optional. O merge registra uma mudança de especificação. Ele não mostra quais clientes já publicam declarações de Bluesky ou Discord, quais verificadores as aceitam ou quais aplicativos migraram listas favoritas.

O limite agora está mais claro. O kind 10011 contém declarações de identidade entre plataformas. O kind 10021 contém ponteiros para follow sets favoritos. A verificação ainda exige buscar a evidência no provedor indicado, e uma prova do Discord pode continuar sem verificação quando o verificador não consegue entrar no servidor.