NIP-84 adiciona tags i aos destaques e afrouxa r

A seção de referências vira uma lista

O texto anterior eram duas frases e cobria dois casos:

a or e tags should be used for nostr events and r tags for URLs.

A substituição é uma lista de três itens:

• a and/or e tags for nostr events
• i tags for structured sources per NIP 73
• r tags for anything else (may contain a URL or text)

Duas coisas aconteceram ali ao mesmo tempo. Um caso foi acrescentado e um caso existente foi redefinido.

O que a tag i traz

O NIP-73 é a especificação de identificadores de conteúdo externo. Ele dá às tags i um vocabulário fixo para identificadores que existem fora do nostr: isbn: para livros, doi: para artigos acadêmicos, isan: para filmes, geo: para geohashes, iso3166: para países e subdivisões, podcast:guid: com suas variantes de episódio e publicador, além de formatos para transações e endereços de blockchain e um formato de URL normalizada sob o tipo web.

Um destaque tirado de um livro não tinha como dizer isso com a redação antiga. O único campo não nostr era r, definido como URL, e um livro impresso não tem uma. Apontar i para o NIP-73 dá a esse destaque um identificador sobre o qual outros clientes podem consultar, que é justamente o objetivo do registro de identificadores: todo evento que carrega ["i", "isbn:9780123456789"] pode ser encontrado como grupo.

Um detalhe que a nova linha deixa de fora. O NIP-73 emparelha cada tag i com uma tag k que nomeia o tipo do identificador, e é isso que faz a consulta por tipo funcionar. O NIP-84 fala em tags i conforme o NIP-73 sem repetir a exigência do k, então esse emparelhamento precisa ser lido no próprio NIP-73.

O que a tag r perde

r não é mais a tag de URL. Agora ela é o recurso de reserva, e a especificação diz claramente que pode conter uma URL ou texto. A pull request descreve a situação que motivou a mudança: destaques publicados com uma fonte que não é uma URL, que os clientes que presumiam uma URL válida não conseguiam interpretar.

Lê-la como URL nunca foi seguro na prática, e a mudança deixa de dar razão às implementações que continuavam a interpretá-la assim. Ela também abre mão de algo. Um cliente não pode mais tratar um valor r de um destaque como um link sem verificar antes.

A mesma edição removeu uma recomendação que acompanhava a definição antiga:

When tagging a URL, clients generating these events SHOULD do a best effort of cleaning the URL from trackers or obvious non-useful information from the query string.

Essa era a única orientação sobre rastreadores no NIP-84, e ela sumiu do arquivo. Nada no diff a levou para outro lugar. Clientes que removem parâmetros de rastreamento das fontes de um destaque agora fazem isso por critério próprio, e não por um SHOULD da especificação, e o formato de URL normalizada do NIP-73, que a via i agora cobre, descarta o fragmento mas não diz nada sobre a query string.

Também ficou uma sobra. O parágrafo final do NIP-84, que esta pull request não tocou, continua dizendo que as URLs em tags r vindas do comentário MUST ter um atributo mention para distingui-las da URL da fonte destacada, e que a URL da fonte MUST ter o atributo source. Esse texto pressupõe que r contém uma URL, o que a seção de referências acima dele já não exige.

Um MUST vira SHOULD

A segunda mudança normativa está na seção de destaques com citação. Uma tag comment transforma um destaque em destaque com citação, e a regra de renderização era absoluta:

This MUST be rendered like a quote repost with the highlight as the quoted note.

Agora ela diz SHOULD. A razão dada no texto ao redor não mudou: a construção existe para que uma única ação de destacar não produza duas notas, um destaque e um kind 1, aparecendo em sequência em clientes de microblog. Um cliente que renderize destaques com citação de outra forma não está mais fora de conformidade.

A edição restante é uma correção de digitação, creation and multiple notes para creation of multiple notes, nesse mesmo parágrafo.

Nada mais mudou no NIP-84. Ele continua draft e optional, o evento continua sendo kind:9802, e as tags p, context e comment mantêm o significado que tinham.