Bem-vindos de volta ao Nostr Compass, o vosso guia semanal de Nostr.

Esta semana: o Amber reforça a autenticação em relays e criptografa segredos armazenados, o Cambium assina para websites sob carga de relay-auth, o Citrine aloja grupos e sites estáticos num relay de telefone, o Vector coloca moderação em fila sob spam e sincroniza silenciamentos entre dispositivos, o Sonar adiciona respostas em mesh com threads, a Nostria publica podcasts e o Nail faz a ponte do e-mail como eventos gift-wrapped. Os lançamentos cobrem estado de grupo do MDK, emissão de emblemas, pareamento de signatário por QR, assinatura no navegador Android e biblioteca partilhada de wallet-connect. O trabalho de protocolo abrange patches de comentários, metadados de ficheiros criptografados, formatação de threads, garantias de reinício do Marmot e listas de membros do Concord. Mergulhos profundos: emblemas e comentários.

Histórias principais

Amber 6.5.0 fecha um confused deputy de relay-auth e criptografa segredos armazenados

O Amber é um signatário Android NIP-55 e NIP-46. A versão 6.5.0 fecha quatro lacunas divulgadas: um confused deputy na autenticação de relays que permitia a qualquer chamador obter um evento NIP-42 de kind 22242 para relays que o utilizador nunca aprovou; uma lacuna de replay NIP-46; segredos de ligação e chaves locais em texto simples agora criptografados em envelope em repouso; e um lote de oito endurecimentos que cobre autorização do chamador antes de descriptografar, parsing de permissões fail-closed, avisos de ws:// simples, ecrãs QR seguros, redação de logs, zeroização preguiçosa de chaves no logout e uso opcional do Keystore com dispositivo desbloqueado.

A versão 6.5.1 reencripta segredos NIP-46 armazenados quando a chave do Keystore roda após alternar o requisito de dispositivo desbloqueado e corrige um crash no editor de permissões. A versão 6.5.2 deixa de descriptografar colunas que a lista de aplicações nunca renderiza, coloca o handle do Keystore em cache, aquece a cache de contas no arranque e faz debounce das notificações de estado de relay.

A 6.4.0 da semana passada tornou explícitas as decisões de assinatura agrupadas; a 6.5.x altera o que o Amber autoriza de todo.

Cambium 0.4.0 assina para websites e alivia rajadas de relay-auth

O Cambium é um proxy Android NIP-55 para um signatário hardware Heartwood via NIP-46. Seis lançamentos saíram em dois dias.

A versão 0.4.0 estende a assinatura a websites. Uma página pode pedir uma assinatura através de um callback nostrsigner: validado sem herdar as permissões concedidas a aplicações nativas, o que impede que um separador do navegador empreste a aprovação de outra app. O mesmo lançamento corrige a forma mínima de evento da especificação: um evento com apenas kind e content assina corretamente, com o Cambium a fornecer a identidade NIP-46 emparelhada, o timestamp atual e um array de tags vazio antes de entregar o evento ao rust-nostr. A instrumentação nativa do rust-nostr tornou-se um gate obrigatório de integração contínua na mesma alteração.

A versão 0.3.6 repara o pareamento contra signatários que seguem a especificação. A compilação antiga do rust-nostr no Cambium aceitava apenas a string literal ack como resultado de uma chamada connect NIP-46, pelo que um signatário que responde devolvendo o segredo do URI do bunker — o que a especificação atual pede e o firmware da Heartwood faz — terminava o pareamento com erro de resposta inesperada. A passagem de rust-nostr 0.44.2 para 0.44.8 torna ambas as formas aceitáveis, verificadas contra hardware real e contra nak bunker, que continua a responder ack.

Os lançamentos 0.4.1 a 0.4.3 tratam do controlo de admissão sob carga. A versão 0.4.1 reserva um slot de fila a reações, publicações, eliminações e encriptação à frente da autenticação de relay e da desencriptação em segundo plano, limita chamadas em fila, descarta-as após timeout do chamador e devolve um resultado terminal de indisponibilidade em sobrecarga em vez de abrir um ecrã de assinatura em primeiro plano. A versão 0.4.2 descarta sessões NIP-46 expiradas ou longamente inativas antes do próximo pedido e deixa cópias concorrentes do mesmo evento de autenticação kind 22242 partilharem uma assinatura hardware. A versão 0.4.3 admite no máximo um desafio de autenticação distinto por identidade no worker hardware, nunca repete autenticação internamente e abre um cooldown de sessenta segundos por identidade após timeout, continuando a responder a duplicados exatos em cache. As medições nas notas de lançamento vêm de um telefone GrapheneOS a conduzir o Amethyst: uma rajada de arranque a frio produziu trinta e três respostas imediatas de sobrecarga e treze pedidos concluídos sem timeouts de signatário; um login fresco durante uma rajada de autenticação regressou 1,254 segundos após aprovação.

Citrine 3.1.0 transforma um relay de telefone em anfitrião de grupos e de sites

O Citrine é um relay Android no dispositivo. A versão 3.1.0 adiciona três capacidades que alteram o que o relay pode alojar.

O suporte para NIP-29, a especificação de grupos baseada em relay em que o próprio relay detém estado de membros e moderação, significa que um telefone pode alojar um grupo em vez de se juntar a um. O suporte para NIP-86, a API de gestão de relay que expõe ações administrativas via JSON-RPC autenticado, chega com um ecrã de definições, pelo que listas de permissão e bans podem ser conduzidos pela API e pela app. O suporte para sites estáticos NIP-5A, definidos na especificação, deixa o relay servir nsites a clientes web, com uma lista de navegação modernizada com ícones, pesquisa, ordenação por última atualização, progresso de instalação, descrições e um conjunto configurável de relays para os obter, por defeito nsite.run, nos.lol e nostr.land.

A superfície de moderação cresceu em paralelo no mesmo lançamento. Banir uma chave pública localmente oferece agora purgar os eventos armazenados desse autor; uma lista configurável REJECTED_KINDS bloqueia kinds que o operador não quer armazenar; o controlo de acesso pode importar de listas existentes. Uma ferramenta de retransmissão empurra eventos armazenados de volta para relays selecionados, o que dá a um arquivo mantido no telefone forma de resemear a rede. O lançamento remove também a extensão WebSocket permessage-deflate, aperta o hot path de consultas, corrige o Tor que falhava ao arrancar ou parar quando a definição de exposição via Tor muda e move logs para uma base de dados local, com logcat limitado a builds de debug.

Vector 0.4.2 faz a moderação comunitária sobreviver a uma onda de spam

O Vector é um mensageiro Concord para desktop e Android. A versão 0.4.2 foca moderação sob carga.

Bans rápidos sobrescreviam-se mutuamente. Agora entram em fila, acumulam-se e resolvem-se como uma única operação, pelo que banir uma onda de contas custa uma rotação de chave em vez de uma por conta. Aceitar um convite para uma comunidade entretanto dissolvida explica agora o motivo e remove o convite de todos os dispositivos do utilizador; dissolver uma comunidade que o utilizador possui limpa-a da lista de comunidades em todo o lado — correção que chegou na versão 0.4.3. Mensagens comunitárias que chegam durante um catch-up em segundo plano deixam de disparar notificações como se acabassem de ser enviadas, e o indicador de escrita expira desde o momento do envio, para que um sinal atrasado não permaneça num canal.

A lista comunitária fragmentada definida pelo Concord passou por uma revisão cruzada com o Armada, o outro cliente Concord. Renomeações deixam de inflar a lista, empates resolvem-se de forma idêntica nos dois clientes e dados inalterados deixam de ser republicados nos relays. Silenciar também saiu do caminho de mensagens diretas: um utilizador pode agora silenciar alguém diretamente numa comunidade sem histórico prévio de mensagens, e o silenciamento aplica-se a notificações e emblemas em canais e DMs, deixando as mensagens visíveis. Mensagens fixadas tornaram-se uma superfície partilhada de canal com links clicáveis, e edições a uma mensagem fixada seguem-na onde quer que apareça. Listas de bloqueio, silenciamentos e alcunhas sincronizam-se agora entre dispositivos do utilizador, assim como chats fixados. A versão 0.4.3 também deixa de anunciar que o utilizador está a escrever quando outro cliente Nostr está autenticado com a mesma identidade, e desbloqueia o bootstrap Tor no Windows, que tinha congelado a quinze por cento em x64 e ARM64.

Sonar traz respostas em thread a um mensageiro mesh com NIP-C7

O Sonar é um mensageiro mesh Bluetooth e Nostr. A versão 0.1-alpha.13.1 adiciona respostas ao estilo Signal em chat NIP-C7 kind 9, mais menções, reassembly Bluetooth limitado, limites de backup, verificação de assinatura de caminho mesh e fallback push FCM. As versões 0.1-alpha.13.2 e 0.1-alpha.13.3 corrigem crashes ao abrir chat no Android e sobreposição do teclado no iOS.

Nostria começa a publicar podcasts e pede contagens aos relays

A Nostria é um cliente web. As versões 4.1.70 e 4.1.71 adicionam publicação de podcasts para subscritores premium, com episódios como eventos Nostr assinados. A versão 4.1.69 usa COUNT NIP-45 para totais de reações, respostas e zaps nos feeds e completa a localização. A 4.1.67 da semana passada expandiu administração comunitária encriptada.

Lançamentos

MDK 0.9.14: histórico de grupo fail-closed com criação de grupo mais rápida

O MDK é o kit de desenvolvimento Rust para o Marmot, um protocolo de mensagens de grupo encriptadas transportado sobre Nostr. A versão 0.9.12 torna vários caminhos de estado de grupo fail-closed em vez de adivinhar. Uma âncora de fork em falta é agora um erro duro (PR #1329); uma proposta de saída persiste-se atomicamente para que um crash não deixe uma partida a meio (PR #1360); e o replay de incidentes recusa adivinhar um formato em fluxos JSON delimitados por newline sem manifesto (PR #1140). Os testes de convergência alargaram-se em paralelo, com recuperação cross-route de histórico retido (PR #1350), garantia de convergência cross-adapter (PR #1372) e campanhas de convergência isolada generalizadas (PR #1357). O diagnóstico de rejeição de relay preserva-se em vez de colapsar numa falha genérica (PR #1361).

A versão 0.9.13 aterrou a 18 de agosto com formato de armazenamento v2 (PR #1421), rails de migração e escritas delta a substituir snapshots de conta ao vivo (PR #1435), recuperação de convites mais rápida (PR #1444) e bindings macOS (PR #1402). A versão 0.9.14 seguiu a 19 de agosto com polimento de criação de grupo: imagens fundadoras pré-carregadas (PR #1498), batching de KeyPackage (PR #1494), retenção atómica de mensagem inicial (PR #1497) e publicação de perfil com relays próprios da conta (PR #1495). MarmotKit 0.9.14 e wn-agent 0.9.14 saem com o crate core.

Divine Mobile 1.0.20: emitir um emblema sem sair da app

O Divine Mobile é um cliente de vídeo curto que publica e obtém vídeo via Nostr. A versão 1.0.20 permite ao utilizador emitir e atribuir a alguém um emblema NIP-58 sem sair da app. Esses emblemas usam os eventos de prémio assinados descritos no primeiro mergulho profundo desta edição. Tocar num emblema num perfil explica o que foi necessário para o ganhar — a parte da especificação que costuma ficar por implementar porque o evento de definição e o de prémio ficam armazenados separadamente.

O resto do lançamento é trabalho de cliente: tema claro, crop, rotação e flip no editor stop-motion, rascunhos a um toque do gravador, timing de legendas face ao vídeo, feed que desprioriza material já visto, suporte a leitor de ecrã no editor, gravador e separadores de perfil, tratamento de movimento reduzido e definições de conta que gerem e-mail e palavra-passe Divine e ligam ou desligam contas. Vídeos eliminados são agora removidos do estado local, e marcadores persistem. A 1.0.19 da semana passada reforçou isolamento de contas e validação de mensagens privadas; emissão de emblemas é uma nova superfície de publicação por cima disso.

ClipRelay 0.2.0: parear um signatário com uma câmara

O ClipRelay sincroniza a área de transferência entre dispositivos via Nostr. A versão Android 0.2.0 adiciona login QR nostrconnect://, para que um utilizador possa autenticar-se com uma app signatária noutro telefone, e leitura por câmara de URLs de bunker, o que remove o hábito de colar uma string com segredo através de um mensageiro. A ligação bunker expira agora após sessenta segundos em vez de ficar pendente, e o botão de retry após login Amber falhado funciona. A versão desktop 0.2.0 traz o timeout e correções no separador de login.

A versão 0.1.4 adicionou sincronização de área de transferência sensível com expiração curta no relay, relays de sessão de signatário fixados e uma sonda de liveness que exige uma ida e volta real em vez de um EOSE sintetizado localmente. A 0.1.3 da semana passada restaurou ligações após períodos ociosos.

Bark 1.3.9: um signatário de navegador que corre no Android

O Bark é uma extensão de navegador que fornece a interface window.nostr NIP-07, o objeto que uma página web chama para pedir assinatura ou encriptação. A versão 1.3.9 declara suporte Android para a build Firefox, para que a listagem de add-ons instale num telefone. O Firefox no Android não implementa API de janelas, pelo que qualquer aprovação que abrisse uma janela popup teria sido negada de imediato; a superfície de aprovação recai agora num separador em primeiro plano onde fechar nega, uma ação de revisão traz-no para a frente e o segundo plano fecha quando o pedido se resolve. As notas de lançamento registam verificação num Pixel 10 Pro XL com GrapheneOS e Firefox 153.0.4, e declaram claramente que o Chromium no Android compila fora o subsistema de extensões, pelo que nenhum navegador Android derivado de Chromium pode executar o Bark.

A versão 1.3.8 corrigiu um defeito de interoperabilidade NIP-46 na direção oposta. O Bark sondava um dialeto compacto de assinatura Heartwood enviando o evento como objeto JSON, o que signatários estritamente tipados incluindo nak e bunkers construídos em rust-nostr não conseguem analisar e descartam silenciosamente, pelo que a assinatura ficava pendente. A sonda envia-se agora apenas a signatários que se identificaram como Heartwood, e todos os outros recebem uma chamada sign_event standard desde a primeira assinatura.

Bray 3.0.0 e Toll Booth 6.0.0 migram para biblioteca partilhada de wallet-connect

O Bray e o Toll Booth pagam ambos via NIP-47 Nostr Wallet Connect, a especificação que deixa uma aplicação pedir pagamentos a uma carteira sobre eventos Nostr encriptados. O Bray 3.0.0 e o Toll Booth 6.0.0 declaram cada um uma alteração breaking ao adotar nwc-kit para pagamentos de carteira, e o Toll Booth remove o seu fluxo de credenciais de pagador na mesma alteração. Ambos publicam builds reprodutíveis cujo output foi byte-idêntico em dois runners independentes, com o hash do tarball impresso nas notas de lançamento para que um leitor possa verificar o artefacto do registo.

Três patches do Toll Booth seguiram: 6.0.1 fixa a chave de host de deploy negociada, 6.1.1 fixa cashu-ts na versão alvo do seu patch, e 6.1.2 restaura uma build de imagem.

O NoorNote é um cliente Nostr para desktop, web e Android. A versão 1.3.4 adiciona comunidades encriptadas Armada e Concord como addon: um utilizador junta-se através de um link de convite, vê comunidades unidas listadas nas definições e recebe notificações de atividade. O mesmo lançamento adiciona um controlo para ocultar publicações de citação externas, os destaques que citam um parágrafo de um artigo web, globalmente ou por autor, com reposts deles também ocultos e os destaques próprios do utilizador mantidos visíveis. A resolução de perfis foi também reparada, pelo que perfis deixam de renderizar como chave pública truncada ou placeholder anónimo.

A versão 1.3.5 adiciona um expansor para notas longas e corrige o layout do campo de entrada de link de convite Armada. A 1.3.2 da semana passada moveu descoberta de artigos para o grafo social; adesão a comunidades é uma superfície separada.

Mostro move chat de disputa para fora do gift wrap

O Mostro é um daemon de trading peer-to-peer cujas ordens e mensagens viajam como eventos Nostr, com mostro-core como biblioteca partilhada e Mostro Mobile como cliente. O Mobile 1.3.2 migra chat de disputa de gift wrap NIP-59 para um envelope de chat kind 14 e sustenta o backlog com cursores duráveis por conversa. O mostro-core 0.14.5 serializa o identificador do rumor dentro do gift wrap (PR #164), o 0.14.4 corrige um bug na média de classificações (PR #163), e o Mobile 1.3.1 muda para servidores Blossom que retêm anexos de chat encriptados. Usar daemon 0.18.2 ou 0.18.4.

NYM 3.73.522: chats de grupo encriptados e armazenamento local encriptado

O NYM é um cliente Nostr com integração de assistente própria. A versão 3.73.522 encripta o armazenamento SQLite local após 3.73.521 refinar chat de grupo encriptado, e 3.73.520 corrige uma quebra de content-security-policy e apresentação duplicada de novas mensagens.

Morganite 0.0.4: verificar um blob antes de o colocar em cache

O Morganite é um servidor Android Blossom, o protocolo de media em que um ficheiro é endereçado pelo hash SHA-256 do seu conteúdo e servido a partir de qualquer host que o detenha. A versão 0.0.4 verifica o hash de um blob durante o download numa única passagem antes de o colocar em cache, que é a verificação que torna o endereçamento por conteúdo significativo no lado receptor. O lançamento também acompanha o tamanho da cache incrementalmente em vez de revarrer o diretório em cada gravação, move chamadas de rede bloqueantes para threads de entrada e saída, reutiliza instâncias Tika para deteção MIME e persiste logs numa base de dados local.

Recém-descobertos

Nail traz e-mail para o Nostr como eventos gift-wrapped

O Nail é uma ponte de correio e cliente web com licença MIT da equipa Formstr, o grupo por trás do Formstr e do nostr-calendar. Foi lançado a 18 de agosto com PR #7, uma alteração de 22 ficheiros que adicionou tags k a eventos de correio, recuperação de chaves nas definições e uma mensagem de boas-vindas. O deployment corre em mailstr.app, que serve o registo _smtp NIP-05 próprio da ponte, o esquema baseado em DNS que mapeia um nome num domínio a uma chave pública Nostr.

O correio em si é um evento Nostr. As constantes do cliente definem um rumor de correio kind 1301 transportado dentro de um gift wrap NIP-59 kind 1059, pelo que uma mensagem chega ao destinatário através do mesmo envelope que oculta metadados usado para DMs privadas. Relays de entrega vêm de uma lista de inbox NIP-17 kind 10050 com uma lista de relays NIP-65 kind 10002 por trás; pastas são etiquetas NIP-32 kind 1985 (eventos de etiqueta) sob o namespace mail; e definições de cliente vivem num evento de dados de aplicação NIP-78 kind 30078. Anexos maiores que 60.000 bytes vão para Blossom em vez de para o evento, porque o NIP-44 limita texto simples encriptado a 65.535 bytes. Um endereço é um npub num domínio, e um domínio local sem registo NIP-05 é tratado como uma caixa de correio inexistente.

A metade ponte é um servidor LMTP Node que corre junto a um deployment mailcow sem o patchar: o Postfix encaminha domínios correspondentes para a ponte, e a ponte injeta respostas de volta via SMTP. Esse desenho força uma resposta honesta à pergunta mais difícil numa ponte de e-mail: o que prova um cabeçalho From. O caminho de receção do Nail classifica cada mensagem num de quatro estados de proveniência: a ponte configurada selou-a e recusa reencaminhar um remetente que não verificou upstream; o utilizador selou-a; o registo NIP-05 do endereço resolve para a chave de selagem; ou nada corrobora o cabeçalho. Nesse último caso a interface recai na chave pública de selagem, que é a única identidade que o evento pode de facto provar. Chamadas à API da ponte autenticam-se com eventos HTTP assinados NIP-98.

Glow armazena etiquetas de carteira em relays sob identidade derivada de passkey

O Glow é uma carteira Lightning self-custodial da Breez. O login com passkey deriva uma identidade Nostr, e a lista de etiquetas de carteira carrega-se e grava-se em relays sob essa identidade, com duplicados byte-idênticos colapsados através de cobertura parcial de relays.

Em desenvolvimento

Amethyst reconstrói o fluxo de decisão de autenticação de relay

O Amethyst é um cliente Nostr Android. Um bloco de trabalho merged remodela como lida com autenticação cliente-para-relay NIP-42. A interface de permissões e o fluxo de decisão foram redesenhados (PR #3899), a autenticação espera agora que um desafio se resolva em vez de expirar (PR #3905), novas contas autenticam-se por defeito sempre com relays (PR #3931), e uma escolha «sempre iniciar sessão» é honrada para relays que a conta não usa (PR #3937). A autenticação reconhece também grupos NIP-29 e comunidades Concord como locais unidos (PR #3906), o que impede que um grupo alojado num relay pareça um relay desconhecido cada vez que é aberto.

Duas outras alterações tocam superfícies de protocolo. Mineração de proof-of-work sob NIP-13 atualiza created_at enquanto mina e ganha análise de caminho GPU (PR #3911), e hosts de napplet em ecrã completo tratam margens da área de introdução (PR #3932). Um backup guiado de chaves na primeira execução com ponto de entrada nas definições também merged (PR #3909), juntamente com silenciar chats públicos (PR #3939).

nostrord implementa proposta de chave de encriptação não merged

O nostrord é um cliente de chat Nostr organizado em torno de grupos com âmbito de relay. Mergeou uma implementação de NIP-4e, uma proposta não merged para desacoplar encriptação de mensagens da chave de identidade que o Compass descreveu pela última vez na edição de 15 de julho. A conta anuncia a sua própria chave de encriptação kind 10044, detém a metade privada localmente e desencripta DMs recebidas no processo, o que tira um bunker ou extensão de navegador do caminho de leitura (PR #261). Pareamento de dispositivos sobre kinds 4454 e 4455 move essa chave para um segundo dispositivo, e um auto-arquivo republica histórico endereçado à nova chave. O envio passou a endereçar primeiro a chave anunciada (PR #247), e um follow-up corrigiu pareamento que negociou com sucesso sem entregar a chave (PR #271). O pull request declara que o formato wire segue a implementação Jumble em produção onde diverge da proposta aberta, o que coloca a definição de trabalho desta especificação em código enviado em vez de no documento.

A identidade de grupo foi apertada no mesmo lote. Um identificador de grupo é agora único apenas dentro do seu relay (PR #269), pelo que o mesmo identificador em dois relays é tratado como dois grupos (PR #272), e publicações de thread renderizam como posts de fórum (PR #274). Churn de ligação que produzia prompts repetidos de assinatura kind 22242 foi também interrompido (PR #268), a mesma classe de pressão sobre signatários em que o Cambium gastou três lançamentos esta semana.

nostream adiciona monitor de relay e emite códigos de convite

O nostream é uma implementação de relay em TypeScript. Mergeou um worker de cluster e agendador de sondas que publicam eventos de monitorização de relay NIP-66, a especificação de descoberta que deixa um monitor anunciar dados de liveness e capacidade sobre outros relays (PR #724), com esquema de definições e defaults (PR #689) e testes de integração (PR #733). Uma ferramenta de linha de comandos emite agora códigos de convite NIP-43, o esquema de metadados de acesso a relay que condiciona admissão (PR #732), e o relay anuncia finalmente proof of work NIP-13 na sua lista suportada (PR #680), que já tinha implementado sem anunciar. Jobs de data vending machine ganharam também migração de persistência e repositório (PR #727), e o relay intercepta agora pedidos de job NIP-90 (data-vending-machine) e regista-os através do repositório de jobs (PR #729).

rust-nostr corrige identificador de gift wrap e rejeita reposts protegidos

O rust-nostr é a biblioteca Rust e SDK por trás de grande parte do trabalho de clientes Rust e móveis nesta edição. Garante agora que o identificador do rumor é calculado antes de o selo do gift wrap ser encriptado (PR #1444), a mesma classe de defeito que o Mostro corrigiu na sua própria biblioteca esta semana. O relay local rejeita um repost de um evento protegido NIP-70 (PR #1445), que é a proteção para a qual essa especificação existe, e o parsing de resposta NIP-47 tolera montantes em falta e nulos (PR #1450) em vez de falhar numa carteira que os omite. O parsing de URL de relay foi reforçado (PR #1451).

NDK adiciona DMs pós-quânticas e remove dependência GPL

O NDK é um kit de desenvolvimento Dart para Nostr. Mergeou encriptação híbrida pós-quântica para mensagens diretas usando ML-KEM-1024, o mecanismo de encapsulação de chaves em lattice normalizado como FIPS 203 (PR #713), colocando-o ao lado do acordo de chaves clássico em vez de no seu lugar. Uma alteração separada substituiu uma implementação Dilithium só GPL-3.0 por fips204, o standard de assinatura ML-DSA (PR #712), o que remove uma restrição de licenciamento para aplicações que embutem o kit. Ligações passaram também a uma identidade cada (PR #710).

Nostter adiciona listas de marcadores, emblemas de perfil e uploads Blossom

O Nostter é um cliente web. Mergeou suporte para formas standard e legacy de listas de marcadores NIP-51 (PR #2311), atualizou o tratamento de emblemas de perfil NIP-58 (PR #2281), adicionou um uploader de media Blossom (PR #2298), e mostra agora um identificador NIP-05, o nome de verificação baseado em DNS, no autocompletar de menções (PR #2303).

Zap Cooking vincula rotas admin a pedidos assinados e encripta ligações de carteira armazenadas

O Zap Cooking é um site de receitas construído sobre eventos Nostr de forma longa. Um lote de segurança encripta strings de ligação Nostr Wallet Connect armazenadas em repouso dentro de um envelope NIP-44 (PR #622), substitui uma comparação de chave pública falsificável em rotas administrativas por autenticação HTTP NIP-98, o esquema que assina um evento para autorizar um pedido HTTP (PR #626), e limpa dados de conta no logout enquanto limita registos NIP-46 pendentes (PR #627).

Trabalho de protocolo e especificação

NIPs

Nenhum pull request merged em nostr-protocol/nips durante esta janela. Seis propostas abriram após o fecho da edição anterior, três delas a 18 de agosto depois de o rascunho ter circulado pela primeira vez.

O NIPs PR #2438 propõe NIP-9A, patching baseado em comentários. Um patch é um comentário kind 1111 que referencia o evento patchado como parent cujo content começa com a etiqueta literal PATCH, seguida de linhas de patch. Uma linha que começa por número edita o content do alvo na forma <index> -<deleted> +<inserted> <caracteres inseridos>, contados em caracteres unicode em vez de bytes, e uma linha que começa por t substitui uma tag legível por humanos como title, description, subject ou picture. O desenho é deliberadamente retrocompatível: um cliente que não entende o formato mostra o patch como um comentário etiquetado ordinário, e um cliente que entende aplica o patch e oculta o comentário. A proposta nomeia kinds 1, 11, 1111, 24 e 1621 como patcháveis e pede a escritores e leitores que recusem patches demasiado grandes, demasiado numerosos ou publicados muito tempo depois do evento original, que é uma tentativa explícita de impedir que a funcionalidade se torne um canal geral de edição para eventos imutáveis.

O NIPs PR #2437 propõe encriptação de ficheiros para NIP-94, a especificação de metadados de ficheiro que descreve um ficheiro carregado num evento kind 1063. Adiciona três tags opcionais: encryption-algorithm, com aes-gcm como único valor listado, mais decryption-key e decryption-nonce codificados em hex. A semântica das tags desloca-se em conformidade, com m a descrever o tipo MIME antes da encriptação, x a deter o hash do ficheiro encriptado e ox o hash do original, e quaisquer fontes thumb, image e fallback encriptadas sob a mesma chave e nonce. O propósito declarado é que um operador Blossom público que aloja os bytes não consiga dizer o que são, e o autor enquadra a alteração como copiar propriedades de encriptação de DMs NIP-17 para metadados de ficheiro para que o mesmo tratamento funcione dentro de uma tag imeta.

O NIPs PR #2436 altera NIP-7D, a especificação de threads de fórum construída sobre eventos de thread kind 11 com comentários NIP-22 kind 1111 como respostas. Adiciona uma secção de formatação que declara que uma publicação de thread pode ser formatada como uma nota kind 1, com imagens inline, links e referências NIP-27, e poderia também suportar Djot, uma linguagem de markup leve com gramática não ambígua. O argumento do autor é que deixar formatação não especificada convida a uma implementação eventual de Markdown por defeito, e o pull request aponta para squalk como implementação Djot existente.

O NIPs PR #2439 adiciona métodos assign e unassign a NIP-86 (comandos de gestão de relay), para que um administrador de relay possa conceder permissões de admin a outra pubkey sem partilhar a chave mestra.

O NIPs PR #2442 sucede a proposta de faixa de áudio que o Compass cobriu em janeiro enquanto aquele rascunho permanecia aberto; o pull request anterior fechou desde então e este está em produção no lightning.fm como eventos de faixa kind 31337, com objetos de lançamento kind 31339, perfis de banda, contribuidores por faixa e splits de zap NIP-57 opcionais mantendo vendas em NIP-99. O contrato de interoperabilidade está publicado em lightning.fm/interop, e o publicador desktop e o daemon de vendedor self-hosted são open source.

Marmot

O Marmot PR #416 merged a 13 de agosto e adiciona um contrato de durabilidade e reinício ao core do protocolo. Os documentos adotados já definiam convergência determinística, material retained candidate-parent, ordenação publish-before-apply e comportamento fail-closed com histórico em falta, sem uma regra inequívoca para o que acontece quando um processo é interrompido nas costuras entre eles. A alteração define factos lógicos recuperáveis, equivalência de reinício, fronteiras de interrupção de publicação e convergência, transições observer-atómicas, tratamento de material em falta ou corrupto e recuperação de efeito de aplicação, e adiciona cenários de conformidade de crash e reinício para cada um. Deixa transacções, journals, snapshots, estratégia de replay, schedulers e formatos de armazenamento definidos pela implementação, e declara que não requer alteração de codificação wire. A falha específica que exclui é uma publicação externamente aceite mas não confirmada localmente, ou um ramo selecionado parcialmente aplicado, produzindo resultados de protocolo dependentes da implementação após reinício.

Concord e CORDs

O Concord PR #18, coberto anteriormente na edição da semana passada como proposta aberta, merged agora a 15 de agosto. Fragmenta a lista comunitária encriptada através de eventos kind 33302, remove o limite de cinquenta membros e poda entradas reformadas para que a lista permaneça dentro dos limites de tamanho de relay. As notas de lançamento do Vector desta semana registam a metade cliente dessa alteração, incluindo resolução de empates e a decisão de deixar de republicar dados inalterados.

O Concord PR #22 propõe brokers de áudio e vídeo próprios da comunidade. A entidade de metadados CORD-02 transportaria uma lista opcional av_brokers ao lado dos seus relays, evoluindo por edição como o resto dessa entidade, e o rendezvous CORD-07 extrairia dessa lista, ou do broker do membro quando a comunidade não publica nenhum, ordenado pelo tie-break room-keyed existente. A tag broker em presença permanece legível e útil para reportar um split residual, e o argumento da proposta para a despromover do routing é directo: routing sobre ela deixa input não confiável de um membro sobrepor-se à instrução própria da comunidade.

O Concord PR #23 torna normativo um comportamento de implementação existente em CORD-05. Antes de persistir uma adesão, a edição de metadados genesis do owner deve abrir sob as chaves entregues, com planos rodados ancorados no par de compactação. O pull request declara de entrada que isto nunca foi uma vulnerabilidade em produção: a aceitação de bundle do Vector recusa um bundle cuja raiz entregue não consegue abrir a genesis do owner e nunca estaciona um convite para uma comunidade já detida, e o Armada descarta qualquer bundle que moveria a base de uma comunidade detida. A lacuna era que nenhum dos comportamentos era exigido pela especificação, pelo que um cliente fiel à especificação poderia ter enviado a versão vulnerável.

Documentos de upgrade Blossom, propostas de aplicação Napplet e a especificação Gamma Markets não registaram alterações nesta janela.

Mergulho profundo em NIPs

Emblemas (NIP-58)

O NIP-58, definido pela sua especificação primária, dá a uma identidade Nostr forma de atribuir um token nomeado a outra, e ao destinatário controlo sobre se aparece no perfil. O problema que aborda é que qualquer declaração sobre uma pessoa no Nostr seria de resto apenas uma nota: não há estrutura que diga quem emitiu uma alegação, como se chama, como parece, ou se o sujeito aceitou. Emblemas dão a essa alegação três eventos assinados separados com três intenções de autores separadas codificadas neles.

A mecânica constrói-se a partir de uma definição endereçável, um prémio e uma lista de exibição. Uma definição de emblema é um evento kind 30009 publicado pelo emissor, endereçável através da sua tag d, para que o emissor possa rever tags name, description, image e thumb mais tarde sem alterar o identificador para o qual tudo o resto aponta. O prémio é um evento kind 8 publicado pelo mesmo emissor, transportando uma tag a com a coordenada 30009:<issuer-pubkey>:<d-identifier> da definição e uma ou mais tags p a nomear destinatários. A lista de exibição é um evento kind 30008 publicado pelo destinatário com o valor fixo d profile_badges, listando pares de tags a e e onde a tag a é a coordenada da definição e a tag e o evento de prémio específico. Esses pares são ordenados e lidos como pares: uma tag a cujo prémio correspondente está ausente, ou uma tag e cuja definição correspondente está ausente, é ignorada, pelo que um emblema meio referenciado não renderiza silenciosamente.

As tradeoffs de desenho são visíveis no que a especificação recusa fazer. Não há mecanismo de revogação nem expiração, pelo que um prémio é uma declaração permanente do emissor sobre um momento no tempo, e um emissor que muda de ideia só pode alterar a definição para a qual o prémio aponta. Não há transferência, pelo que um emblema não circula como token. Não há noção de registo de emissor confiável, o que empurra toda a questão de confiança para o cliente e o leitor: um emblema vale exactamente o que a chave pública do emissor vale para quem o vê. A especificação concede também latitude aos clientes para mostrar menos emblemas do que o destinatário listou e escolher que tamanho de imagem renderizar, o que impede que um perfil se torne um mural de gráficos escolhido inteiramente por terceiros.

A especificação adjacente mais próxima é o NIP-51, a especificação de listas, e comparar as duas mostra porque emblemas precisam de três eventos em vez de um. Uma lista é um único autor a curar referências; o autor da lista é o autor da alegação. Um emblema divide autoria a meio, com o emissor a assinar que o prémio aconteceu e o destinatário a assinar que aceita a sua exibição. Nenhuma das partes pode produzir sozinha o resultado visível, o que separa um emblema de uma etiqueta auto-aplicada.

Um prémio kind 8 ao vivo recuperado de nos.lol e relay.primal.net esta semana:

{
  "id": "08504dec368939bd63849a349cab83dea0ac199a852129dbf68cf35fe5c64e96",
  "pubkey": "bef514bd58c8ceea4beb9e6b84a8d983935f7be26f49e14df68098f1ba64156e",
  "created_at": 1787051248,
  "kind": 8,
  "tags": [
    ["a", "30009:bef514bd58c8ceea4beb9e6b84a8d983935f7be26f49e14df68098f1ba64156e:blocks_orange_league"],
    ["p", "92dfa05d915196a7a09152fa3f57871debfd422e1d278ac5af266a70c3350b1f", "wss://relay.damus.io"]
  ],
  "content": "Badge awarded!",
  "sig": "5bf0218dfec5e56b47339b0b4b992cceedd2e18798fb3d47cafea51850c00827f66251e4a3e08190370e04a5e1d4d092eeb441141b7219acdd18b80290a022f8"
}

Implementações actuais cobrem emissão, exibição e leitura. O Divine Mobile 1.0.20 emite e atribui um emblema dentro da app e explica um emblema ganho quando um leitor toca nele, o Nostter PR #2281 atualiza tratamento de emblemas de perfil num cliente web, e o Amethyst publica eventos de prémio com a sua própria tag de cliente, uma das quais aparece em dados de relay junto ao exemplo acima.

Comentários (NIP-22)

O NIP-22, definido pela sua especificação primária, fornece um evento de comentário geral para responder a coisas que não são notas de texto curto. Threading de notas curtas já tinha o NIP-10, cujas convenções de tags cresceram em torno de kind 1 e das suas cadeias de resposta. O NIP-22 existe porque um vídeo, um artigo, um evento de calendário, uma página wiki ou um URL precisa de uma estrutura de resposta que identifique que tipo de coisa está a ser respondida, e que funciona quando o alvo é endereçável, ou é um recurso externo sem evento Nostr algum.

A mecânica assenta numa distinção de maiúsculas. Um comentário é um evento kind 1111 que transporta dois conjuntos de tags: tags maiúsculas descrevem a raiz da discussão e tags minúsculas descrevem o parent imediato. E, A e I nomeiam um evento raiz, uma coordenada endereçável raiz ou um identificador externo raiz, K nomeia o kind da raiz, e P nomeia o autor da raiz. As variantes minúsculas e, a, i, k e p nomeiam os mesmos factos sobre o parent, que é a própria raiz num comentário de topo e outro comentário kind 1111 numa resposta aninhada. Separá-las significa que um cliente pode obter uma discussão inteira com um filtro nas tags raiz maiúsculas, sem percorrer a cadeia de respostas, enquanto renderiza aninhamento correctamente a partir das tags parent minúsculas. As variantes I e i transportam identificadores externos no formato NIP-73, o que deixa uma thread de comentários ligar-se a uma página web, um episódio de podcast ou um livro.

As tradeoffs são sobretudo sobre o que o NIP-22 declina absorver. A especificação declara que comentários não devem ser usados para responder a notas kind 1, o que impede que dois modelos de threading compitam sobre os mesmos objectos e deixa o NIP-10 no lugar onde já funciona. Aninhamento é permitido mas a raiz permanece fixa, pelo que uma thread profunda nunca perde a sua âncora mesmo quando eventos intermédios estão indisponíveis. As tags de kind são a parte estrutural: um cliente que obtém um comentário sem o seu alvo ainda consegue dizer a que se dirige a partir de K e k, e decidir se consegue renderizar esse kind. O que a especificação não fornece é qualquer modelo de ordenação ou moderação, pelo que ordem de exibição, colapsar e ocultar são inteiramente política de cliente.

Comparado com o NIP-10, a diferença está na tipagem. O NIP-10 assume que o alvo é uma nota e codifica posição numa thread; o NIP-22 codifica identidade e kind do alvo explicitamente e não assume mais nada sobre ele. Essa tipagem explícita é porque as propostas mais recentes desta edição recorrem ao kind 1111: um comentário já transporta uma declaração legível por máquina sobre aquilo a que está ligado.

Um comentário kind 1111 ao vivo recuperado de nos.lol e relay.primal.net esta semana, a responder a outro comentário sob um vídeo:

{
  "id": "c8d335f8bfea58ecd1a943d6000fb2045f4bddf4a36c67df53eb661671f7ab45",
  "pubkey": "3e911baba55ae247339cf805dd6ff49ad2cd6bee84ac44e088ce66450c49104f",
  "created_at": 1787062681,
  "kind": 1111,
  "tags": [
    ["E", "1c492f2bac17b79d66934a340fa43d8d30d0aea4c9fa329346c05573ef912d70", "", "482d024b8acfde50e7429e5ac561d764f3a53a8b4fb0b6975369d9f0926ef839"],
    ["A", "34236:482d024b8acfde50e7429e5ac561d764f3a53a8b4fb0b6975369d9f0926ef839:e64ba9ea157b1a315caff51dbca656ed73ce817d4494e3966adf24055a86f5c5", ""],
    ["K", "34236"],
    ["P", "482d024b8acfde50e7429e5ac561d764f3a53a8b4fb0b6975369d9f0926ef839"],
    ["e", "7a14723b9ef999e74b1757a0fb74942cb6c121138d4ddafe096a57a67ed0a442", "", "8b69e548402afa997343d73e8088224a440f256350f6257b61acc4bb1fa4af4f"],
    ["k", "1111"],
    ["p", "8b69e548402afa997343d73e8088224a440f256350f6257b61acc4bb1fa4af4f"],
    ["client", "Divine", "31990:d95aa8fc0eff8e488952495b8064991d27fb96ed8652f12cdedc5a4e8b5ae540:divine-mobile", "wss://relay.divine.video"]
  ],
  "content": "niiice",
  "sig": "a5517fdea07647efa7ab1730fbea8df882690bba667e93ea5aeba4a73be6a49af1ee17c045535483650caf41dbbcb0897d5803fa39b59f395fd6f9bb193bb789"
}

As tags maiúsculas detêm o vídeo e o seu autor enquanto e e k minúsculas apontam para o comentário parent, que é a forma que a especificação descreve. Implementações que leem e escrevem kind 1111 incluem o Divine Mobile, cuja tag de cliente aparece no evento acima, o Amethyst, cujos comentários aparecem nos mesmos resultados de relay, e o nostrord, que renderiza publicações de thread como posts de fórum esta semana. O formato de patch proposto no NIPs PR #2438 constrói sobre o mesmo kind.

Envie uma DM NIP-17 para partilhar um projeto ou notícia através do projeto Nostr Compass.