Resumo da Semana: Nove Pull Requests Mesclados no nostr-protocol/nips

NIP-59: um novo tipo de gift wrap efêmero para mensagens em tempo real

O PR #2245 adiciona o kind:21059, uma contraparte efêmera do kind:1059 já existente para gift wrap. Ele tem a mesma estrutura do kind:1059, mas segue a semântica de eventos efêmeros definida no NIP-01, o que significa que os relays NÃO DEVEM armazená-lo. O NIP-59 agora explicita a divisão pretendida: kind:1059 é para mensagens persistentes e assíncronas, como as conversas do NIP-17 que precisam de entrega offline, enquanto kind:21059 é para contextos em tempo real, como chat ao vivo ou jogos, onde só importam os destinatários conectados naquele momento. Isso não muda como as mensagens diretas do NIP-17 funcionam hoje: adiciona um segundo tipo de gift wrap, não persistente, para casos de uso que não precisam de histórico de mensagens.

NIP-17: mensagens diretas em gift wrap ganham uma seção de exclusão e edição

O PR #2260 adiciona uma seção "Delete and Edit" ao NIP-17. Ela estabelece que, além do comportamento de exclusão já especificado no NIP-59, no qual um gift wrap pode ser excluído pelo destinatário marcado com a tag p, os clientes PODEM permitir que um usuário exclua uma mensagem embrulhando um evento de exclusão kind:5 dentro de um gift wrap kind:1059 e enviando-o ao destinatário como parte da conversa. Os clientes DEVERIAM então remover a mensagem excluída da conversa, ou marcá-la como excluída. A mesma seção também permite implementar a edição de mensagens como uma exclusão seguida da publicação de um novo evento com o mesmo timestamp. Essa é uma orientação nova adicionada sobre o formato de gift wrap existente, não uma mudança na criptografia em si.

NIP-01: relays devem tratar segmentos de caminho extras como o mesmo endpoint

O PR #2307 adiciona uma única frase ao NIP-01: "Relays MUST only accept connections to a single endpoint when additional path segments do not influence its behavior." A descrição do PR aponta que uma URL de relay como wss://relay.example/<random-string> era, na maioria dos relays em funcionamento, funcionalmente idêntica a wss://relay.example/, uma ambiguidade que dificultava aos clientes raciocinar sobre a identidade e a deduplicação de relays.

NIP-29: espaços ao vivo de áudio e vídeo para grupos

O PR #2238 adiciona uma seção ao NIP-29 que permite a um grupo anunciar uma sala de voz e vídeo com LiveKit por meio de uma tag livekit no evento de anúncio do grupo, junto com uma nova tag supported_kinds que lista quais tipos de evento o grupo aceita (uma lista vazia significa que ele não aceita nenhum kind, apenas a sala de áudio/vídeo). Os clientes solicitam um token de entrada ao endpoint /.well-known/nip29/livekit/<group-id> de um relay usando um evento de autorização do NIP-98, e os relays podem publicar quem está na sala no momento por meio de um novo evento de participantes kind:39004.

NIP-71: múltiplas faixas de áudio por vídeo

O PR #2255 estende as convenções da tag imeta no NIP-71 para que um único vídeo possa listar várias faixas de áudio como tags imeta separadas, cada uma com uma propriedade l para o idioma e uma propriedade ov indicando a faixa no idioma original. Também adiciona uma propriedade waveform, uma pequena lista de valores de amplitude separados por espaço, para que os clientes possam renderizar a forma de onda de uma faixa de áudio.

NIP-78: um kind normal e não endereçável para dados específicos de aplicação

O PR #2292 adiciona o kind:78 ao NIP-78 como evento normal, ao lado do kind:30078 endereçável já existente. A distinção importa para aplicações que precisam armazenar e consultar vários eventos do mesmo tipo: um kind endereçável mantém apenas o evento mais recente por tag d, enquanto um kind normal mantém todos eles. O PR também adiciona o novo kind à tabela de tipos de evento do README dos NIPs.

NIP-85: descrição reformulada do kind:10040

O PR #2304 reformula um único parágrafo do NIP-85. Ele muda o texto que descrevia o kind:10040 como uma lista de "provedores de serviço confiáveis" para descrevê-lo, em vez disso, como a fonte preferida do usuário para cada resultado, e esclarece que um provedor de serviço pode usar múltiplas chaves e relays, incluindo uma chave emitida por usuário quando os resultados são personalizados para aquele usuário.

C7: visualizações de chat restritas ao kind 9

O PR #2310 adiciona uma linha à convenção C7: clientes que renderizam uma "visualização de chat" como um fluxo ordenado de eventos DEVEM buscar apenas eventos kind:9, para evitar perder contexto entre implementações diferentes. Outros tipos de conteúdo ainda podem ser referenciados dentro de uma mensagem kind:9 por meio de citação, conforme o NIP-18.

NIP-F4: um novo NIP em rascunho para podcasts

O PR #1093 é, de longe, a maior mudança do dia: adiciona uma especificação completa em rascunho com mais de cem linhas novas. Ele introduz o NIP-F4, um NIP em rascunho e opcional que define como programas e episódios de podcast são publicados nos relays e lidos a partir deles como eventos Nostr, estruturado para se encaixar nos fluxos de trabalho de tocadores de podcast já existentes. No NIP-F4, cada podcast tem seu próprio par de chaves Nostr, o que permite combinar a presença como podcast com um perfil comum kind:0/kind:1. As informações do programa, como título, imagem de capa, descrição e site, são publicadas como um evento substituível kind:10154, que também pode creditar apresentadores, coapresentadores e editores por chave pública. Os episódios individuais são eventos kind:54 separados, publicados diretamente pela própria chave do podcast, cada um com título, descrição e uma ou mais tags audio apontando para o arquivo de mídia do episódio. Como qualquer pessoa poderia, do contrário, alegar falsamente ser autora de um podcast, o NIP-F4 adiciona um evento kind:10064 por meio do qual os autores reais de um podcast publicam sua própria lista dos podcasts que autoram, de modo que uma autoria alegada possa ser verificada contra essa contraclaim em vez de aceita sem checagem. O PR também atualiza o NIP-51 para adicionar uma lista "Favorite podcasts" do tipo kind:10054, permitindo que qualquer usuário indique publicamente quais podcasts segue usando tags p para as chaves públicas dos podcasts e tags url para as URLs dos feeds RSS/XML, e adiciona os novos kinds de evento à tabela de kinds do README dos NIPs.

Um lote, não um lançamento coordenado

Além das duas mudanças sobre mensagens diretas, não há um fio condutor ligando esses nove pull requests. Eles tocam partes não relacionadas do protocolo, do tratamento de conexões de relays ao vídeo em grupos, ao armazenamento de aplicações e à distribuição de podcasts, e simplesmente passaram pela revisão dentro da mesma janela de cerca de noventa minutos em 28 de maio. Foi um lote, não um lançamento temático, ainda que a maior mudança do dia, de longe, o novo NIP de podcasts, tenha chegado na mesma janela que outras oito, muito menores.