Nostr Compass #42

Bem-vindo de volta ao Nostr Compass, seu guia semanal sobre Nostr.

Nosso aplicativo Android dedicado do Nostr Compass reúne newsletters, episódios de podcast, guias de tópicos e notas de voz de colaboradores em um só lugar. Suas notas de lançamento assinadas mais recentes descrevem newsletters completas com assinatura verificada, edições salvas e 110 guias de tópicos disponíveis offline, além de busca local nas matérias e nas transcrições disponíveis. Colaboradores podem gravar e responder com notas de voz, revisar uma gravação salva antes de enviá-la e assinar pelo Amber sem armazenar a chave privada no aplicativo. As gravações públicas são publicadas no Nostr e no Blossom.

A atualização mais recente do aplicativo preserva gravações na fila e pontos de retomada de upload quando o Android interrompe o trabalho em segundo plano, mostra quando a aprovação do Amber é necessária e abre a gravação correspondente a partir de uma notificação. As visualizações separadas de episódios e de notas de voz mantêm suas próprias posições de rolagem, enquanto a reprodução continua do mesmo ponto. As notificações de novas gravações dependem do agendamento e das permissões do Android.

Nesta semana: o White Noise adiciona enquetes criptografadas em grupo e avisos de histórico de chat incompleto; o Holoboard adiciona comandos de promoção por mensagem privada e um aplicativo Android; o fips-pub-domains testa nomes públicos assinados em uma malha; o Marmot MDK torna visível o histórico ausente de grupos criptografados; e o Myco dá ao compartilhamento de aplicativos entre aparelhos próximos uma identidade Nostr e uma loja. O nostream ajusta a admissão do relay à carga, enquanto o Nostr double ratchet fecha uma brecha envolvendo membros removidos. O desenvolvimento corrige a interoperabilidade de grupos criptografados do Amethyst, adiciona as mensagens de vídeo criptografadas do Divine e coloca o Nostr Atlas no ar. As atualizações de protocolo refinam provas de identidade, convites de relay, conjuntos de follows e propostas de reivindicação de domínio. A retrospectiva de setembro de fim de mês acompanha as mesmas questões ao longo de seis anos de Nostr.

Principais destaques

Holoboard adiciona comandos de promoção via Nostr e um aplicativo Android

O Holoboard é um mural para encontrar notas do Nostr por meio de um ranking que pode ser impulsionado com pagamentos Lightning. As postagens originais continuam sendo events do Nostr; o Holoboard serve seus dados de ranking e de aparência por meio de sua própria API HTTP. Essa distinção importa se o leitor espera que a ordenação do mural seja um feed nativo de relay.

Seu changelog de 23 de setembro registra comandos de promoção por mensagem direta tanto pelo caminho criptografado do NIP-17 quanto pelo caminho legado do NIP-04. O NIP-17 embrulha mensagens privadas para ocultar seu conteúdo e seu remetente dos relays, enquanto o NIP-04 é o formato mais antigo de criptografia de mensagens diretas. Um usuário pode pedir uma fatura de promoção na mesma conversa, receber uma cotação identificada para a primeira promoção paga e optar por lembretes de expiração respondendo YES. O remetente das promoções tenta novamente nos relays que falharam, enquanto a atualização de 24 de setembro adiciona um aplicativo Android e simplifica o fluxo de faturas.

As notas de integração com relays do projeto descrevem notas e comentários comuns no Nostr, roteamento para caixa de entrada criptografada e tratamento de citações e exclusões. Sua listagem Android assinada no Zapstore comprova a existência de uma versão do aplicativo, mas a chave da listagem não foi estabelecida como a identidade pública do mural do Holoboard. Esta é a primeira cobertura do projeto no Compass.

fips-pub-domains testa nomes públicos assinados para uma malha

O fips-pub-domains é um novo experimento de resolução e nomeação que vincula nomes de domínio públicos a nós do FIPS, uma malha criptografada que usa mensagens Nostr para descoberta de peers. Sua primeira versão combina essas reivindicações com registros DNS TXT, validação DNSSEC opcional, vínculos fixados localmente, um daemon de resolução para Linux e integração Android com o fips2go, o cliente FIPS para celulares. Uma reivindicação assinada, por si só, não estabelece a posse de um domínio público; os clientes precisam de evidências de DNS ou DNSSEC, de uma testemunha configurada ou de um pin previamente confiável.

A versão 0.2.0 adiciona provas DNSSEC às reivindicações para que um cliente com acesso apenas a um relay da malha possa validar um nome não fixado, e permite que vários servidores validados atendam a um mesmo domínio. Ela também corrige pins desatualizados e o failover de DNS. A versão 0.2.1 corrige uma unidade systemd que, de outra forma, falhava ao iniciar e executa o servidor sem root; instalações existentes precisam substituir essa unidade para receber a correção.

No Android, uma mudança incorporada ao fips2go segue vínculos de nomes públicos verificados em seu proxy DNS. Uma segunda mudança incorporada leva as conexões com relays Nostr configurados pela malha, de modo que o resolvedor pode obter e verificar uma reivindicação de domínio ainda não vista enquanto o celular está sem conexão com a internet. Os resultados nos dispositivos são relatados pelos mantenedores nesses pull requests; eles não estabelecem uma implantação mais ampla.

Os testes com dois nós e com relay apenas na malha do projeto são evidências relatadas pelo mantenedor para uma implementação inicial, e não uma implantação em produção. Sua proposta de NIP-DB (proposta aberta) ainda está aberta, e os kinds de event em seu rascunho continuam como marcadores provisórios à espera de registro. A matéria da semana passada sobre o fips2go abordou a inicialização da malha e a descoberta de peers; o trabalho desta semana trata de nomes públicos e verificação.

Marmot MDK 0.11.0 torna visíveis lacunas no histórico da conta

O Marmot MDK, o runtime em Rust e os bindings gerados para mensagens em grupo no Nostr criptografadas com MLS, dá sequência à versão de envio durável da semana passada com a versão 0.11.0. A recuperação de conta agora só declara uma lacuna de histórico como concluída depois que todos os relays necessários terminam uma comparação de events sem truncamento; uma lacuna não comprovada gera um aviso durável que o aplicativo hospedeiro pode mostrar ao usuário. Uma fila de entrega cheia transborda para o banco de dados da conta em vez de descartar events, e a entrega ao vivo avança o cursor de transporte para que uma reinicialização não busque o mesmo histórico de novo.

As notas de lançamento completas também descrevem enquetes em grupo criptografadas opcionais, verificação de events sem estado nos bindings e bibliotecas Android alinhadas para páginas de memória de 16 KB. Os aplicativos devem migrar juntos os bindings gerados e as bibliotecas nativas desta coorte de código-fonte; os bancos de dados de conta migram até o schema 98 na primeira abertura, e o downgrade do banco de dados não é suportado. Um defeito intermitente já existente na sincronização de atraso ainda pode deixar mensagens com mais de cinco epochs de grupo de atraso impossíveis de descriptografar sem gerar aviso, portanto esta versão não afirma recuperar o histórico completo em todos os casos.

Myco 0.8.0–0.8.1 dá aos aplicativos de aparelhos próximos sua própria loja Nostr

O Myco é um aplicativo Android para trocar pequenos programas Nostr, chamados napplets, com celulares próximos, inclusive quando estão offline. A versão 0.8.0 dá a cada instalação uma identidade Nostr de convidado e permite login com uma chave existente ou com o Amber, um signer Android que aprova assinaturas sem compartilhar a chave da conta. Ela também substitui a aba Descobrir por uma loja de aplicativos que é, ela própria, um napplet. Essa loja lê listagens e recomendações de aplicativos assinadas, enquanto uma atualização baixada pode passar entre os celulares do Circle de um usuário sem conexão com a internet.

A versão 0.8.1 facilita encontrar essas listagens ao consultar os relays que um autor anuncia; as versões anteriores dependiam de padrões públicos. Ela mostra imediatamente perfis e aplicativos em cache, guarda respostas mais lentas dos relays para visitas posteriores, recua diante de relays com falha e mantém as assinaturas ativas enquanto uma visualização está aberta. As duas atualizações preservam o formato de comunicação existente entre celulares. Celulares atualizados podem baixar e compartilhar atualizações de napplets; celulares mais antigos apenas encaminham os anúncios.

Lançamentos com tag

White Noise Android adiciona enquetes em grupo e padrões de mensagens temporárias por conta

O White Noise Android é um mensageiro Nostr para conversas privadas criptografadas com Marmot. Depois das melhorias de entrega e compartilhamento abordadas na semana passada, a versão de 30 de setembro adiciona enquetes em grupo com respostas selecionáveis, barras de resultado e prazos por meio do Marmot Development Kit. Ela também adiciona padrões de mensagens temporárias locais ao dispositivo para cada conta: novas conversas diretas e grupos herdam a duração escolhida, enquanto conversas existentes e suas configurações individuais mantêm a política atual. O Wave hi envia uma saudação que menciona um membro recém-adicionado sem atrapalhar o rascunho em andamento.

A versão permite escolher o ponto focal do recorte de imagens de perfil e de grupo e excluir uma pasta de chats sem excluir suas conversas. Seus avisos de histórico mostram quando a recuperação deixa o histórico da conta ou do grupo possivelmente incompleto, com controles de dispensa separados. A paginação de conversas evita reconstruir a linha do tempo exibida ao saltar para mensagens recentes, e as edições de mensagens pendentes conservam o texto enquanto o envio original obtém seu ID de event confirmado. Essa passagem de edição cobre mudanças de conversa dentro do aplicativo em execução; ela não estabelece persistência caso o processo seja encerrado.

O ditado agora escolhe Colar ou Enviar para cada gravação, e a finalização automática coloca a transcrição no rascunho. A configuração do provedor offline explica o processamento no dispositivo, mantém seu consentimento separado do de outros provedores de fala e retoma mídias interrompidas quando a captura termina. O tratamento de arquivos em geral aceita documentos não vazios e de tamanho limitado, com nomes de arquivo, metadados MIME e mensagens de falha precisos; os downloads explícitos de anexos usam as tarefas de transferência iniciadas pelo usuário do Android, com alternativa em primeiro plano. Os controles de colar agora usam a ação do sistema Android para que o Secure Paste do GrapheneOS possa conceder acesso à área de transferência. O Android também exibe compartilhamentos do GIPHY feitos no iOS como mídia animada, respeitando a política de download.

As correções de notificação atualizam os apelidos dos remetentes e limpam os alertas quando uma conversa é aberta. As mudanças de recuperação de notificações preservam o trabalho de push pendente quando o controle em primeiro plano não está disponível e usam novas tentativas limitadas. A assinatura pelo Amber coordena rajadas de aprovação da mesma conta para evitar que limites de taxa cancelem envios. A nova configuração de auditoria pede uma nova escolha sobre compartilhamento de logs antes de enviá-los ao novo receptor. O código-fonte também adota a licença AGPL-3.0-only.

nostream 3.1.0 ajusta a prova de trabalho do relay à carga

O nostream é um relay Nostr em TypeScript apoiado em PostgreSQL. A versão 3.1.0 pode elevar ou reduzir o limite de prova de trabalho dos events, dentro de limites definidos pelo operador, conforme muda a taxa de events observada. A configuração vem desativada por padrão, usa a taxa medida de cada worker e mantém independente o limite estático por chave pública já existente, de modo que os operadores precisam optar por ela antes que os remetentes vejam um requisito de admissão diferente.

A mesma versão adiciona um painel administrativo com métricas de relay, WebSocket e events, resultados de sondagens de saúde da rede e notificações configuráveis para o operador. Sua API administrativa vem desativada por padrão. Esses controles ajudam os operadores a distinguir problemas de pressão no relay e de alcançabilidade, mantendo a nova política sob configuração explícita.

Depois da versão com prova de trabalho sensível à carga, o nostream incorporou ações para denúncias de moderadores confiáveis. O NIP-56 define events de denúncia de conteúdo; a nova opção nip56.hideActionableReports exclui events denunciados dos resultados de REQ e COUNT quando as denúncias também estão ativadas. Uma denúncia de event oculta esse event, enquanto uma denúncia de chave pública oculta todos os events daquele autor. A nova opção tem padrão falso, então ativar apenas a coleta de denúncias preserva os resultados de consulta existentes.

Nostr double ratchet 0.0.171–0.0.172 fecha uma brecha envolvendo membros removidos

O Nostr double ratchet é uma biblioteca TypeScript para chats privados criptografados transportados pelo Nostr. A versão 0.0.171 rotaciona a chave de remetente de um grupo após mudanças na associação, para que alguém removido com as chaves antigas não consiga descriptografar mensagens posteriores de um remetente atualizado, mesmo depois que esse remetente reinicia. Ela também recusa envios ou rotação de chave por um proprietário local removido e aborta um envio se a associação mudar durante a distribuição de chaves.

A versão 0.0.172 leva a aprovação de dispositivo já assinada pela conta em uma resposta de convite criptografada opcional. Um destinatário que use a atualização pode verificar o dispositivo do remetente antes que chegue um event de registro separado, enquanto dispositivos vinculados mantêm sua aprovação após reinicializações. O campo do convite é opcional e deixa intactos o handshake original e o formato das mensagens do ratchet.

As versões 0.0.173–0.0.175 ampliam esse trabalho de remoção com repasses duráveis de chaves de grupo e estado de entrega em fila salvo antes da publicação, para que repasses interrompidos se recuperem após a reinicialização. Os callbacks de publicação levam um contexto local de grupo que permite aos aplicativos cancelar novas tentativas duráveis após uma remoção, mantendo entregáveis os controles de associação; envios em fila preservam os IDs originais de seus events internos. Respostas de convite duplicadas preservam as sessões estabelecidas, as assinaturas permanecem estáveis conforme os contatos mudam, e os snapshots de chaves de aplicativo mantêm os nomes dos dispositivos sem compartilhar cópias mutáveis. O formato assinado de comunicação permanece inalterado; as notas da 0.0.173 também relatam a versão Rust 0.0.168, com fallback de sessão de recebimento e filtragem local de ecos de grupo.

Scramble 0.7.4–0.7.5 busca as mensagens que um novo membro do grupo deve ver

O Scramble é um mensageiro de grupo Marmot multiplataforma com interface Android nativa. Na versão 0.7.5, cada grupo recebe seu próprio ponto de corte de histórico no relay: antes, o ponto de corte da conversa mais ativa era aplicado a todos os grupos, então um grupo recém-ingressado podia continuar vazio porque suas mensagens posteriores à entrada nunca eram solicitadas. O caminho de reconexão recebe a mesma correção, e um grupo sem atividade local agora solicita todas as mensagens disponíveis; o MLS continua impedindo que um novo membro descriptografe mensagens enviadas antes de sua entrada.

A versão 0.7.4, anterior, corrige a aceitação repetida de convites causada por linhas recicladas do Android que acumulavam handlers de clique, e faz com que a configuração de um servidor de mídia Blossom personalizado persista no aplicativo nativo. A versão 0.7.5 distribui apenas o APK Android nativo, então usuários que acompanham o nome de arquivo antigo do Avalonia precisam mudar o alvo de atualização. Contas e histórico passam entre essas duas versões Android, mas grupos criados com o motor MLS 0.6.x antigo não migram para a 0.7.x.

O Scramble 0.7.6 adiciona um controle manual Fetch missing messages que consulta todos os endereços de roteamento já usados por um grupo, remove a restrição de tempo, corrige um endereço armazenado desatualizado e informa o que foi recuperado. Ele ainda não consegue descriptografar epochs anteriores à entrada do usuário. Administradores no aplicativo nativo podem promover ou rebaixar outros membros, com o estado atual da lista e resultados de falha visíveis; conversas entre duas pessoas continuam ocultando esses controles. A ação Copy das informações do grupo agora responde, embora conversas por convite ainda possam copiar um identificador interno do chat em vez do ID de grupo do protocolo. A versão 0.7.7 também libera mensagens retidas quando chega o commit de outro membro; a 0.7.8 adiciona um teste de regressão para esse caminho de membro passivo.

Amber 6.6.6 corrige segredos de conexão com o signer remoto

O Amber é um signer Android que aprova assinaturas de events Nostr sem entregar a chave da conta ao aplicativo. Depois da mudança na criptografia de backups da semana passada, a versão 6.6.6 corrige seu parser de nostrconnect: um parâmetro de conexão contendo =, como um segredo com padding, era alterado antes que o Amber respondesse. Isso fazia clientes baseados em NDK falharem na verificação do segredo mesmo quando a conexão com o signer parecia válida.

A versão também envia issues de feedback para os relays anunciados pelo anúncio do repositório do Amber, com fallback para o relay anterior se o anúncio não puder ser obtido. Tempos limite maiores no Tor dão a relays lentos mais tempo para confirmar essa publicação. As demais mudanças melhoram a visibilidade de ícones e textos nos temas do Amber.

FIPS 0.5.2 interrompe um vazamento de privacidade na descoberta via Nostr

O FIPS é uma malha criptografada que usa identidades Nostr e mensagens de relay para descobrir peers. Sua versão de manutenção 0.5.2 deixa de assinar pedidos de exclusão de travessia de NAT com a chave de roteamento do nó, o que vinculava essa chave ao tráfego de travessia nos relays. Ela também atualiza a biblioteca TLS usada nas conexões com relays para uma versão que corrige um alerta de segurança publicado e repara vários casos de mensagens perdidas na renovação de chaves de link e de sessão.

As notas de lançamento recomendam que operadores de todas as plataformas atualizem, e detalham correções separadas para permissões do arquivo de chave no Windows, gateway e serviço de pacotes. Nós efêmeros não gravam mais um fips.key privado que uma reinicialização posterior poderia sobrescrever; operadores que pretendiam ter uma identidade estável devem configurar o modo persistente antes de atualizar. A versão não muda o formato de comunicação da malha, então nós com versões diferentes podem ser atualizados individualmente.

napplet soyLI 0.23.1–0.23.4 corrige a publicação de backends e a aprovação do signer

O soyLI do napplet.soy é o kit de criação e publicação para pequenos programas Nostr em sandbox. Depois da versão de criações compartilhadas da semana passada, a versão 0.23.1 inclui manifestos, handlers e schemas de backend nas verificações do criador e nas prévias multiplayer. Ela mantém a configuração portátil de provedores no manifesto do projeto, deixando vínculos de identidade privados e bancos de dados de desenvolvimento fora do snapshot de código-fonte publicado.

A versão 0.23.2 permite que projetos que antes fizeram commit de um contexto público de backend gerado voltem a publicar após validação rigorosa, enquanto continua rejeitando vínculos privados, journals, bancos de dados e credenciais presentes no histórico alcançável. A versão 0.23.4, posterior, corrige uma falha de sessão em backends persistentes que podia rejeitar uma aprovação válida de extensão ou de signer remoto quando a pessoa levava vários segundos para assinar. Hosts públicos também precisam da correção do host compartilhado; atualizar apenas o CLI de um criador não corrige um host já implantado.

Dart NDK 0.10.0 delimita a autenticação no Blossom e a assinatura remota

O Dart NDK é uma biblioteca Flutter e Dart para acesso a relays, assinatura, solicitações de carteira e operações de mídia no Nostr. Depois da pré-versão da semana passada, a 0.10.0-dev.7 faz com que as solicitações de mídia ao Blossom permaneçam anônimas até que um servidor as recuse, e então as autoriza por meio de uma política explícita que diz qual identidade uma operação pode revelar. Ela leva essa autorização por todo o caminho da solicitação e substitui as opções antigas useAuth e customSigner, uma mudança de integração incompatível para aplicativos que usam a API da pré-versão.

A dev.9 deixa de reter a resposta de um signer remoto até que o relay mais lento a confirme. A dev.8 reduz o polling de relays em segundo plano e o trabalho de cache; suas outras correções tratam da persistência da seed da carteira e de prazos de liquidação. A versão estável 0.10.0 agora empacota essa série de desenvolvimento junto com as mudanças de metadados de conexão e de IDs privados de assinatura descritas abaixo. A comparação com a dev.9 inclui essas mudanças incorporadas. Aplicativos que atualizarem devem revisar tanto a mudança de API de autenticação de mídia quanto o caminho de resposta do signer remoto.

A versão estável inclui metadados de conexão e permissões solicitadas do NIP-46, substituindo campos de conexão separados por um valor Nip46ClientMetadata. Trata-se de uma mudança de API no código-fonte que permite aos widgets de login passar a identidade do aplicativo e as permissões solicitadas ao bunker. Outra mudança nos IDs de solicitação usa 32 caracteres hexadecimais aleatórios em produção, mantendo nomes de casos de uso e fases de paginação fora dos IDs de assinatura visíveis aos relays. IDs explícitos continuam limitados ao máximo de 64 caracteres do NIP-01, enquanto o modo de depuração mantém um nome curto para diagnóstico.

Mostro Core 0.16.0 remove o antigo transporte por gift wrap

O Mostro Core fornece o protocolo de mensagens usado pelos clientes e pelo coordenador de negociação peer-to-peer do Mostro, baseados em Nostr. A versão 0.16.0 remove o transporte por gift wrap da versão 1 do protocolo e suas antigas funções de wrap e unwrap, deixando o transporte mais novo como caminho da biblioteca. É uma mudança incompatível para aplicativos que ainda constroem ou leem mensagens v1 por meio desta biblioteca.

A versão da biblioteca antecede a versão 0.19.0 do coordenador, já publicada. Operadores que atendem clientes mais antigos precisam atualizar os dois lados da migração de transporte. A tag 0.15.1, anterior, adiciona um estado de disputa para cancelamento cooperativo, mas o marco de compatibilidade é a remoção do transporte.

Cambium 0.6.0–0.7.1 registra um celular de desbloqueio por meio de mensagens de relay

O Cambium é um companheiro de assinatura para Android que trabalha com uma chave de hardware Heartwood e também pode desbloquear a placa após uma reinicialização. A versão 0.6.0 permite que um celular se registre para desbloqueio pelos relays Nostr da placa, sem cabo USB; o usuário compara cinco palavras da solicitação no celular, na placa e no Sapwood, a interface de registro da placa, antes de pressionar o botão da placa. Relays recém-anunciados recebem um atraso de conexão aleatório para que o primeiro contato do celular não revele exatamente quando ele viu a atualização da placa.

A versão 0.7.0 inverte o fluxo de convite: o celular escaneia o QR code de curta duração do Sapwood e devolve um único event criptografado de uso único, a partir de uma chave descartável. A nova tentativa republica esse mesmo event se nenhum relay o aceitar, enquanto o antigo caminho de exibição de código continua disponível para versões mais antigas do Sapwood. O patch 0.7.1 mantém visível o código de verificação final e melhora a reprodutibilidade da compilação no F-Droid; o fluxo por QR ainda exige as versões recentes especificadas do Sapwood e do Heartwood.

Bray 3.5.0–3.5.2 limita gastos de carteira Nostr iniciados por agentes

O Bray é um servidor de ferramentas Nostr que permite a um assistente de IA solicitar ações de relay, identidade e carteira por meio de uma interface com escopo definido. Sua versão 3.5.0 adiciona um teto para cada pagamento via Nostr Wallet Connect e um orçamento diário persistido, com confirmação humana quando o host do assistente oferece suporte. Servir conexões de gasto separadas agora exige uma configuração explícita do serviço de carteira, verifica novamente cada concessão antes do uso e restringe as consultas de faturas aos hashes dentro dessa concessão.

A versão também orienta os usuários a guardar a URI de conexão da carteira em um arquivo privado em vez de colá-la no chat, e se recusa a repetir um pagamento incerto como se a falha estivesse comprovada. A versão 3.5.2 faz a correspondência dos meios de pagamento do marketplace localmente, depois que relays rejeitaram o filtro de método de pagamento solicitado. Essas verificações limitam o quanto um assistente delegado pode gastar e evitam que uma suposição sobre filtros de relay esconda ofertas correspondentes.

Mafrend 1.3.0-alpha migra grupos privados de mapa para o Marmot atual

O Mafrend é um aplicativo social Nostr baseado em mapas que permite explorar lugares e conversar sobre destinos. Sua versão 1.3.0-alpha atualiza os grupos privados para uma especificação mais nova de grupos criptografados Marmot e adiciona visualizações de perfil a partir de chats e avaliações. O formato de grupo é incompatível com chats de versões alpha anteriores; os usuários devem tratar isto como uma migração alpha com quebra de compatibilidade.

A mesma versão adiciona compartilhamento de capturas de tela e mudanças no chat, junto com melhorias de mapa e marcadores. Os recursos de perfil ainda estão marcados como em andamento pelo projeto. A mudança relevante para o Nostr é a alteração de interoperabilidade dos grupos privados; usuários com grupos de teste antigos devem verificar a nota de compatibilidade antes de atualizar.

Sonar alpha.15–alpha.15.1 corrige a publicação em grupos criptografados

O Sonar é um mensageiro privado que pode transportar conversas por malha Bluetooth e pelo Nostr. A alpha.15 adiciona reações com emoji às mensagens e compartilhamento privado do horário local dentro de chats criptografados, com uma configuração para revogar esse compartilhamento. Sua carteira passa a usar Cashu, mas essa mudança de pagamento é separada da atualização de mensagens.

A alpha.15.1 corrige uma falha na inicialização que podia deixar o índice de conversas vazio depois que uma compilação de uma branch mais antiga gravava uma versão de schema estranha. Sem o índice, o aplicativo recriptografava e republicava compartilhamentos de horário local para todos os grupos a cada reabertura, às vezes enviando centenas de events antes que os limites de taxa dos relays interviessem. O hotfix reconstrói esse estado local e interrompe as publicações repetidas nos grupos.

Pacotes de comércio do Elisym introduzem pedidos privados no Nostr

O Elisym é um kit de ferramentas para agentes baseado em Nostr que agora está construindo um fluxo de comércio com events assinados. Seu pacote commerce incorporado define produtos de loja, autorização do proprietário, pedidos e recibos embrulhados de forma privada e verificação de ofertas para os componentes de checkout e de comerciante. Uma tag commerce 0.2.0 posterior deriva a referência de pagamento de um pedido a partir do próprio pedido, vinculando a consulta do pagamento ao fluxo de compra assinado.

A série de pacotes também introduz trabalho separado de núcleo de pagamentos e de checkout no navegador, mas suas tags de versão não estabelecem que um checkout completo de comerciante esteja implantado. O kind de event de autorização da loja é explicitamente provisório na fonte primária do projeto. As onze tags de SDK, MCP, CLI e núcleo de pagamentos marcam um único recurso de comércio em desenvolvimento.

As novas versões de pacotes do Elisym empacotam o nó de comerciante auto-hospedado, enquanto o MCP 0.31.0 adiciona buy_product e get_order para produtos de comércio. Versões posteriores de commerce e merchant-node adicionam suporte a pagamentos Tempo dentro desse mesmo checkout. Esses pacotes avançam a integração existente de produtos assinados e pedidos privados; a lista de tags não torna o schema de event provisório um padrão nem estabelece o lançamento completo de um serviço hospedado.

Flotilla 1.11.2 destrava signers e feeds incompletos de relays

O Flotilla é um cliente Nostr para conversas, salas e espaços compartilhados. A versão 1.11.2 dá ao usuário uma saída quando a inicialização trava esperando um signer remoto e encerra a sessão cujos dados locais do aplicativo foram apagados. Uma sala agora pode exibir suas mensagens antes que o espaço mais amplo termine de sincronizar, enquanto os feeds deixam de omitir postagens só porque um relay respondeu depois de outro.

A mesma versão também publica uma compilação para o F-Droid assinada com a chave existente do aplicativo e mantém as versões no GitHub atualizadas para o Obtainium. Esse trabalho de distribuição importa para usuários que estão trocando de canal de atualização, mas as correções de relay e de signer são o motivo imediato para atualizar.

Ditto 2.42.3 mostra a entrega nos relays e reforça os limites entre contas

O Ditto é um cliente social Nostr que permite aos usuários escolher seus relays e se autenticar neles. Na versão 2.42.3, os Detalhes do Event de uma postagem mostram quais relays do usuário e do autor a armazenam; o Broadcast mira apenas os que estão faltando. A versão também aponta relays de leitura que não respondem e oferece um controle para tentar de novo, tornando mais fácil diagnosticar uma postagem ausente sem reenviá-la para todos os lugares.

As notas de lançamento dizem que trocar de conta não envia mais postagens aos relays da conta anterior, que usuários silenciados não podem disparar alertas genéricos no celular e que links ou imagens em postagens não podem alcançar dispositivos na rede local do leitor. Postagens de relays lentos deixam de desaparecer dos feeds Follows e Loved, enquanto o chat de transmissões ao vivo e os jogos webxdc se atualizam sem baixar repetidamente a visualização inteira. Navegação de torrents e de áudio também é novidade, mas o roteamento de relays e o isolamento de contas são as mudanças com maior impacto no Nostr.

Iris Chat 2026.9.24.4 traz chamadas para conversas criptografadas

O Iris Chat é um mensageiro Nostr com criptografia de ponta a ponta que usa a família de protocolos de chat double ratchet. Sua versão de 24 de setembro adiciona chamadas de voz e vídeo com contatos compatíveis, inclusive por uma conexão local existente quando a internet não está disponível. O usuário pode reduzir a qualidade do vídeo, atender uma chamada de vídeo apenas com voz e lidar com uma chamada recebida pela interface de chamadas do Android; atender ou recusar também faz os outros dispositivos vinculados pararem de tocar.

A versão também permite entrar por meio de um aplicativo de assinatura separado e ver quais dispositivos vinculados estão conectados. Os patches posteriores de 24 de setembro mantêm os horários originais de mensagens atrasadas e melhoram a entrega entre aparelhos próximos depois de um pacote de reconexão perdido. São comportamentos iniciais de chamadas e de múltiplos dispositivos, então a atualização é mais útil para contatos que podem rodar versões compatíveis do Iris.

A atualização de 30 de setembro, posterior e assinada pelo desenvolvedor, mantém o histórico local de grupo de um membro removido enquanto desativa seus envios, melhora a entrega entre dispositivos vinculados e em grupos grandes e corrige indicadores de leitura e contadores de não lidas. As chamadas ganham seleção de dispositivo de áudio e a volta dos tons de chamada efetuada; um status de microfone desatualizado não silencia mais o áudio recebido. Silenciamento temporizado, cópia de imagens, anexos por arrastar e soltar, roteamento de notificações e registro de push recebem correções, enquanto sair da conta limpa os caches locais e remover um dispositivo encerra sua sessão. Uma segunda atualização melhora o acesso a arquivos armazenados em cache por outros aplicativos Iris no mesmo dispositivo e mantém disponível o compartilhamento local de arquivos com o Nearby desativado.

LibreNostr 0.6.0–0.7.0 roteia relays pelo Tor embutido

O LibreNostr é um cliente Nostr para Android com configurações de relay e de privacidade ajustáveis. A versão 0.6.0 inclui um motor Tor baseado em Arti para ARM64 e aplica o modo escolhido, Direto, Tor para tudo ou apenas .onion, aos WebSockets de relay, solicitações HTTP, mídia, uploads e páginas web. O modo Tor estrito falha de forma fechada quando o Tor não está disponível e nunca envia uma solicitação diretamente sem aviso; mudar de modo reconecta os sockets de relay pela nova rota.

A versão 0.6.2 adiciona um filtro de web of trust no dispositivo, construído a partir de listas públicas de follows, e escolhe relays complementares pela quantidade de pessoas seguidas adicionais que eles alcançam. A versão 0.7.0 passa então a mostrar notas e notificações antes que as consultas de perfis e contagens terminem, limita consultas lentas aos relays e deixa de descriptografar toda a caixa de entrada de DMs a cada abertura de conversa. Juntas, essas versões mudam tanto para onde o cliente pode se conectar quanto por quanto tempo um relay lento pode travar sua interface.

Sua primeira versão estável, 1.0.0, assinada pelo desenvolvedor, adiciona decks para tablet salvos por perfil, com colunas móveis para feeds, hashtags, perfis, leitura de formato longo, notificações e mensagens. Tablets em modo paisagem recebem esse layout; celulares mantêm a interface atual. A busca ganha OR, exclusões, filtros de mídia e intervalos de datas funcionais, retorna perfis em cache antes dos refinamentos vindos dos relays e passa imediatamente adiante quando uma solicitação de texto completo é recusada. As hashtags são ordenadas cronologicamente, a paginação espera respostas suficientes dos relays, e feeds não usados liberam suas assinaturas.

A mesma versão preserva as entradas públicas e criptografadas existentes das listas de silenciados e de favoritos durante edições, em vez de substituí-las por uma única alteração. Ela isola favoritos e notificações entre contas e restringe os relays auxiliares de autores a leituras públicas, mantendo solicitações privadas e autenticação de relay longe deles. Também impede que respostas de perfil desatualizadas substituam metadados mais novos, corrige a paginação e os badges de notificações, mantém itens antigos do feed quando chegam novos e corrige as contagens regressivas para desfazer respostas, publicações duplicadas, URLs de mídia com query strings e contadores de não lidas após marcar um chat como lido. A versão 1.0.1 corrige uma falha na inicialização do deck para tablet no novo layout.

Newlay 0.3.45 transmite grandes consultas de relay em vez de encerrá-las

O Newlay é um relay Nostr hospedado em Android, com serviços locais relacionados. Seu anúncio assinado da versão 0.3.45 diz que grandes resultados de consulta agora são transmitidos com backpressure, em vez de encerrar a conexão do cliente. O host Git embutido remove packs obsoletos após os pushes, enquanto seu coordenador de mensagens criptografadas Cordn aceita solicitações de cliente grandes demais e envia um frame de aborto quando uma sondagem expira.

A versão também dá ao operador Android um cartão de status ao vivo com events, armazenamento, endereço e administração, e alinha a biblioteca nativa de criptografia para dispositivos com páginas de memória de 16 KB. As mudanças no relay e no coordenador abrangem várias versões desde a versão anterior na loja, a 0.3.39; a 0.3.45 é o ponto de controle empacotado delas.

ngit-grasp 3.0.5 mantém pushes Git e sincronização de relays em andamento

O ngit-grasp é um relay Nostr e servidor Git auto-hospedado para colaboração em repositórios assinados. Seu anúncio assinado da versão 3.0.5 tira a reconciliação lenta de histórico do ator compartilhado de sincronização ao vivo, permitindo que as assinaturas de relay comecem enquanto events anteriores são verificados. Ele aplica backoff separado para limites de taxa, consultas de histórico incompletas, leituras de caixa postal e buscas de identidade, para que um relay com problemas não monopolize mais a capacidade de novas tentativas.

A mesma versão reconcilia com o inventário local de events para evitar buscar de novo o histórico armazenado e fecha assinaturas incompletas antes de tratar sua cobertura como verificada. No lado do Git, ela aceita pushes que a promoção de estado em segundo plano já aplicou, mantém a proteção contra conflitos para refs alteradas e drena a saída de progresso do Git durante uploads para evitar um push travado. Esses detalhes importam porque um repositório pode parecer ativo nos relays enquanto sua transferência Git ainda espera um resultado definitivo.

Armada 0.63.0 leva alertas push a todos os tipos de signer

O Armada é um cliente Nostr para comunidades criptografadas, canais e mensagens diretas. Depois da versão de privacidade de mídia da semana passada, seu anúncio assinado da 0.63.0 descreve um novo caminho de push no navegador que funciona com o aplicativo fechado para logins por extensão e por signer remoto, além de outros tipos de conta. O Tenna, um aplicativo hospedeiro que incorpora o Armada, também ganha notificações em segundo plano para seus usuários.

A versão carrega mais rápido as mensagens antigas em canais longos de comunidades e evita reler todo o histórico em busca de mensagens novas. Os indicadores de digitação em mensagens diretas usam menos conexões com relays. As atualizações no desktop ganham um aviso de reinicialização, enquanto atualizações diretas a partir de versões anteriores à 0.50.0 deixam de ser suportadas.

A continuação 0.63.1, assinada, adiciona pacotes de emoji editáveis com importação de pastas e reordenação, busca mensagens citadas além do histórico carregado e torna interoperáveis as respostas hospedadas em relays. Ela reduz o tráfego de reconexão no Android, recupera o atraso após desconexões longas sem repetir alertas antigos, exclui menções anteriores à entrada e preserva campos de grupo não editados e entradas privadas da lista de servidores. Exclusões em grupos hospedados em relays agora exigem o autor da mensagem ou um administrador. O arrastar de servidores, o tratamento de informações de relay malformadas e as assinaturas de repositórios também recebem correções.

A versão 0.63.2 amplia o Markdown das mensagens para citações e listas aninhadas, linhas horizontais, blocos de código, títulos sublinhados e formatação que atravessa links ou menções. Links de páginas do Tenor e do Giphy são reproduzidos como GIFs. A sincronização do estado de leitura transfere menos dados, a reconexão evita downloads e logins redundantes, e as notificações em segundo plano do Android pausam a sincronização com os relays quando grandes atualizações de configurações a inundam.

deed 0.3.0–0.3.2 torna mais estável a publicação Nostr em Zig

O deed é uma ferramenta de linha de comando em Zig para ler e publicar events Nostr. Sua versão 0.3.2, de 24 de setembro, adiciona uma skill para agentes e corrige os prazos de ping aos relays; as versões anteriores 0.3.1 e 0.3.0 melhoram o desempenho e a confiabilidade da publicação. As três tags descrevem uma única série inicial da ferramenta. O benefício visível para o Nostr é uma conexão com relays e um caminho de publicação de events mais estáveis para scripts que usam o CLI.

Cordn 0.5.1 mantém outros grupos funcionando quando um coordenador falha

O Cordn é um mensageiro de grupo criptografado com MLS que usa identidades e relays Nostr para localizar coordenadores de conversa. Sua versão assinada 0.5.1 do cliente dá sequência ao trabalho de fila offline da semana passada separando o agendamento do coordenador e o da caixa de saída: um coordenador indisponível não atrasa mais envios para grupos não relacionados. Dicas de relay resolvidas persistem após a descoberta, os documentos de grupo as levam entre dispositivos, e um registro durável de publicações pendentes recupera envios encalhados. A recuperação em múltiplos dispositivos sobrepõe consultas da cadeia de histórico e de lacunas enquanto lê a configuração atual.

A versão também adiciona anexos por arrastar e soltar, grupos fixados, nomes de perfil em prévias e notificações e rótulos de coordenador. Ela corrige o posicionamento na primeira mensagem não lida, os contadores de não lidas, alertas duplicados, prévias de mídia e de mensagens do sistema, respostas anexadas a mídias com legenda e os controles de zoom de imagens. Os downloads nativos usam um seletor Salvar como. Um signer que aparece com atraso não provoca mais um falso aviso de criptografia não suportada, e a troca de contas não entra mais em condição de corrida com a semeadura em segundo plano.

Nymbot 1.0.7 adiciona tratamento local de documentos e compartilhamento criptografado de chats

O Nymbot é um assistente acessado por mensagens Nostr criptografadas com gift wrap. Sua versão 1.0.7, assinada pelo desenvolvedor, lê documentos no dispositivo, seleciona trechos relevantes quando um arquivo é grande demais para ser enviado inteiro e identifica as páginas usadas. As conversas podem ser compartilhadas por um link com criptografia de ponta a ponta cujo acesso pode ser revogado depois. Respostas em Python e JavaScript podem ser executadas localmente, com a saída devolvida à conversa.

A mesma versão adiciona pesquisa com fontes e preço mostrado antes do envio, edição de imagens, seleção de modelo por mensagem e limites de gasto por chat e por bot. Ferramentas externas conectadas via MCP pedem confirmação antes de alterar dados. Execuções em repositórios podem pausar mudanças para revisão, exibir resultados de CI e retomar depois de um gateway ocupado. Respostas sugeridas, avisos fixados, listas de fontes recolhidas e um seletor de modelos pesquisável completam a atualização; essas afirmações vêm das notas de lançamento do desenvolvedor; o Compass não auditou de forma independente a privacidade do aplicativo.

0xchat 1.5.6 distribui suas correções de assinatura e autenticação de mensagens

O 0xchat é um mensageiro Nostr com chats privados, assinatura externa e recursos de carteira. A versão 1.5.6 distribui as correções de segurança abordadas como merges no código-fonte na semana passada, incluindo autenticação de gift wraps, configuração de infraestrutura confiável e consentimento para assinatura em páginas incorporadas. Ela também fecha caminhos de desvio do proxy Tor, valida certificados TLS para hosts que não são onion e impede que compilações de produção gravem no console do dispositivo credenciais e material de carteira potencialmente sensíveis. Logs de desenvolvedor, ativados por opção, continuam registrando erros.

A versão espaça as reconexões aos relays de três segundos até cinco minutos, corrige assinaturas após a reconexão e entrega solicitações enfileiradas enquanto um relay está se conectando. Trocas de conta deixam de acumular listeners de relay duplicados, um login com falha preserva a conta já ativa e as conexões com signers externos persistem entre inicializações. Envios com falha agora mostram erros e mantêm o texto não enviado ou o estado recuperável de compartilhamento de tokens. A descriptografia de chaves na inicialização e o cálculo de hash de uploads saem da thread de interface; os caches de chat e de vídeo evitam renderizações e downloads repetidos. A versão fornece arquivos para Android e desktop com checksums SHA-256, incluindo o APK Android assinado pela Play e um instalador para Windows compilado a partir do código-fonte.

Nostr Mail Client 0.17.0 oculta dos relays as ações na caixa de correio

O Nostr Mail Client troca e-mails pelo Nostr e também oferece suporte à entrega de e-mail convencional. Depois da versão da semana passada com transporte por destinatário e privacidade de mídia, a versão 0.17.0 oculta dos relays o estado de leitura, arquivamento, pastas e etiquetas, e o momento em que eles mudam, e permite excluir e-mails sem notificar o remetente. A versão exige atualizar todos os dispositivos juntos, porque clientes mais antigos não veem o novo estado nem as exclusões. Ela também protege destinatários em Cco em e-mails maiores que 32 KB, mantém apelidos locais de contatos fora das mensagens enviadas, corrige o login por QR do Amber e publica e-mails públicos nos relays de leitura dos destinatários.

A versão adiciona pastas e etiquetas coloridas com regras por remetente, assunto e anexo; citações em respostas e encaminhamentos; imagens coladas em linha; prévias e renomeação de anexos; e seleção por intervalo nas listas de e-mails. O encaminhamento mantém as imagens e os anexos originais, as citações em respostas começam recolhidas e o editor web ganha um menu de contexto. Tabelas HTML e imagens em linha são renderizadas com mais precisão, links em texto simples funcionam e o agendamento aceita datas até cinco anos à frente. Nomes e fotos do catálogo de endereços aparecem em toda a interface, e as cores do tema oferecem paletas do sistema, sugeridas ou personalizadas.

A mesma versão mantém locais os planos de fundo escolhidos a partir de arquivos e guarda em cache os planos de fundo vinculados, com um custo de migração explícito: planos de fundo antigos baseados em arquivo nas plataformas nativas precisam ser adicionados de novo. Ela muda as recomendações padrão de relays e mídia, adiciona descoberta de aplicativos Nostr no onboarding e nos avisos de atualização, preserva configurações desconhecidas gravadas por outros clientes e corrige a criação interrompida do armazenamento de e-mails e o empacotamento para Linux. Falhas na inicialização agora mostram detalhes e um relatório pré-preenchido, em vez de uma tela em branco.

Nostr WoT 0.8.7 vincula a autenticação ao destino

O Nostr WoT é uma extensão de navegador que combina assinatura Nostr com ferramentas de confiança. A versão 0.8.7 exige consentimento para a autenticação HTTP assinada do NIP-98 vinculado à URL exata, à query, ao método, à conta e à origem solicitante. Aprovações amplas antigas exigem novo consentimento. A autenticação de relay do NIP-42 tem um sistema de permissões separado e vinculado à conta, no qual negações específicas de um site têm precedência sobre permissões compartilhadas de relay. As solicitações de autenticação precisam vir de uma origem de navegador de nível superior verificada, e esperas por aprovação ou desbloqueio disparam outra verificação de conta e acesso.

A versão verifica assinaturas remotas do NIP-46 e o event aprovado completo, para que uma assinatura devolvida não possa substituir silenciosamente o conteúdo ou o destino. O provisionamento da carteira e as mudanças de endereço usam autenticação vinculada ao corpo, desafios de backend de uso único e tokens de transação separados; a assinatura genérica de sites não pode emitir esses tokens internos de carteira. O backend compatível precisa ser implantado primeiro, e o cliente se recusa a voltar para endpoints desativados. Os pagamentos via Nostr Wallet Connect também verificam a preimage de pagamento devolvida contra o hash da fatura solicitada e tratam uma divergência como resultado desconhecido.

Na interface de solicitações, os usuários podem inspecionar events brutos completos, escolher solicitações específicas em um grupo de um site e ver mensagens privadas localmente sem aprovar seu retorno a um site. As prévias locais se ocultam após 30 segundos; as solicitações recebidas permanecem desmarcadas, e a aprovação em lote comum exclui autenticação. A extensão separa concessões de relay por site e para todos os sites, limita o cache de perfis verificados, resolve events substituíveis com o mesmo timestamp pelo menor ID de event e mantém locais as leituras de publicação do popup inicial. Chrome e Firefox recebem pacotes verificados separadamente e fluxos de envio de versões estáveis serializados; esses fluxos não comprovam a disponibilidade atual nas lojas.

O runtime compartilhado do Iris mantém consistentes o histórico de relays e de peers

O nostr-pubsub fornece um runtime compartilhado de events Nostr com armazenamento persistente de events e uma fila de publicação de saída. As versões 0.5.7–0.5.13 agrupam assinaturas exatas, as reproduzem após a reconexão, mantêm distintas as evidências locais, de relay e de peer e informam histórico incompleto quando o armazenamento durável falha. Consultas concluídas esperam que todos os events recebidos terminem a admissão. O lote padrão para relays agora contém no máximo 20 filtros OR, por compatibilidade com servidores comuns, enquanto os lotes para peers mantêm correspondência e cancelamento independentes.

As atualizações do runtime do Hashtree substituem a rede específica de workers por esse runtime compartilhado, índices persistentes de events e uma fila de saída, permitindo que events e arquivos em cache compartilhem um único nó FIPS. O FIPS TypeScript 0.0.44–0.0.45 seleciona rotas com capacidade suficiente para registros completos de sinalização, recupera configurações de sessão descartadas dentro do prazo do handshake e só tenta novamente respostas WebRTC após rejeição explícita do roteamento. Rotas WebSocket com frames maiores exigem peers nativos compatíveis; as notas da 0.0.44 exigem implantar primeiro o FIPS nativo 0.4.85.

O Iris Kit 0.2.5 adiciona um cliente de aplicativo persistente para events simples e assinatura NIP-46 independente de transporte, preservando as chaves da conta e as leituras offline. A versão 0.2.6 devolve imediatamente, a partir do worker ou do backend nativo, um ID de event completo já verificado; consultas por prefixo e de events substituíveis ainda esperam o histórico antes de escolher o valor mais recente. São versões de biblioteca, e as notas não estabelecem a implantação em todos os aplicativos Iris.

A atualização de código-fonte do Iris Meet de 30 de setembro substitui sua integração com o NDK por uma infraestrutura persistente de publish/subscribe e signers de identidade compartilhados. O patch adiciona cobertura para restauração offline de identidade, assinatura NIP-07 e isolamento de salas de reunião. O aplicativo de reuniões existente usa o Nostr para sinalização criptografada e WebRTC para áudio e vídeo. Trata-se de progresso de implementação na branch padrão; o repositório não tem uma versão com tag que comprove que esta atualização específica chegou ao site ao vivo.

Chama propaga cancelamentos de anúncios e alertas em segundo plano

O Chama usa events assinados para negociação comunitária e conversas privadas. As versões 6.4.14–6.4.16 publicam um cancelamento assinado antes de excluir um anúncio localmente, para que outros clientes possam retirar a mesma oferta em cache. As tags de despertar do destinatário agora acompanham os events independentemente da configuração de notificações do remetente, e o servidor de alertas elimina duplicatas pelo event assinado, de modo que um chat logo após uma entrada ainda pode disparar um despertar. Tarefas em segundo plano reprocessam negociações afetadas a partir de cursores salvos, isolam cadeias com falha e descriptografam o texto das notificações localmente; a versão exige reimplantar o watcher complementar.

As versões agrupadas também aplicam as renovações de participantes nos horários de seus events assinados, colocam em quarentena bloqueios de financiamento feitos depois que uma vaga expirou e expõem a recuperação da nota ao portador salva. A publicação de reivindicações espera a importação ou o pagamento confirmado. Os filtros de anúncios preservam a moeda do visualizador entre escopos de comunidade, e os cabeçalhos das negociações usam o valor final de entrada. Essas mudanças alinham o que dois clientes conectados ao Nostr deduzem do mesmo histórico de events.

Earthly 0.1.12 adiciona configurações de mapa reutilizáveis

O Earthly é um editor colaborativo de mapas no Nostr com publicação assinada e compartilhamento criptografado. A versão 0.1.12 adiciona configurações reutilizáveis do GMapper para mapas públicos do Google My Maps, descoberta de Maplets criados por desenvolvedores, armazenamento privado ou publicação pública de configurações e cópia de geometrias com atribuição. A mesma versão adiciona compartilhamento criptografado de conexões, inserção de entidades por arrastar e navegação do chat no celular. A disponibilidade de exportação do Google e o CORS dos navegadores limitam a importação, Maplets executáveis baixados continuam indisponíveis no Tauri, e as verificações de atualização em dispositivos Android físicos continuam pendentes.

O trabalho de configurações migrou endereços de publicação e preferências existentes e adicionou revisão ou retirada de atualizações de configuração. Seu fluxo inicial para Android falhou antes da compilação; uma correção de ferramentas preparou a versão marcada em seguida.

Mostro 0.19.0 aposenta seu transporte de primeira geração

O Mostro coordena negociações peer-to-peer pelo Nostr. A versão 0.19.0 agora distribui a remoção de seu transporte por gift wrap de primeira geração, então os clientes precisam usar o protocolo mais novo. As tags de timestamp existentes de criação de ordens e abertura de disputas foram renomeadas para published_at sem mudar os valores armazenados; o created_at do event que as contém continua sendo o horário de assinatura. As respostas de restauração devolvem a chave de negociação da contraparte, as operações aceitas de criar e aceitar ordens reconhecem chaves de negociação, e a publicação nos relays é concluída na primeira confirmação positiva de um relay. A mesma versão atualiza prazos e cancelamento de garantias, encerra disputas quando uma negociação é resolvida, notifica o mediador e limita a defasagem de preços retransmitidos.

A correção de admissão de chaves de negociação do Mostro reconhece uma chave assim que a ordem ou disputa que a introduz é confirmada. Nós com prova de trabalho mais rigorosa para o primeiro contato podiam antes descartar uma mensagem legítima de acompanhamento até a atualização periódica de chaves conhecidas; limites iguais ao padrão não eram afetados. Uma transação de disputa confirma atomicamente a transição da ordem e a linha da disputa, eliminando falhas de estado inconsistente. As notificações de encerramento enviam ao mediador designado, em regime de melhor esforço, uma mensagem privada quando os usuários resolvem uma disputa, e o event substituível existente continua sendo a alternativa offline.

SCRUTINY Lens traz pesquisa de segurança para o Nostr

O SCRUTINY Lens v0.1.0, sua primeira versão pública, de 29 de setembro, é um cliente de navegador para metadados de segurança publicados pelo Nostr. Analistas podem buscar por CVE, por identificadores de pacotes ou de certificados, inspecionar históricos de events e retratações e explorar relações em um grafo de assuntos. O navegador verifica as assinaturas e os identificadores dos events. A busca e as explicações opcionais com IA usam um endpoint escolhido pelo usuário; o aplicativo confere as citações transcritas contra os events subjacentes. As notas de lançamento descrevem explicitamente as limitações dos relays e identificam dependências de compilação local que ainda exigem repositórios irmãos.

Mangatsu e Noteds chegam ao Android

O Mangatsu v0.1.11 faz parte da primeira série de versões Android desta semana do leitor e publicador de quadrinhos. Seu código-fonte adiciona login com o Amber por meio do NIP-55, a interface Android para pedir a um signer externo que aprove operações Nostr. Quadrinhos e capítulos são events Nostr, enquanto suas páginas ficam em servidores Blossom; o leitor também oferece uma biblioteca salva criptografada e leitura offline. Commits posteriores tratam da invocação do signer e da atualização de listas de relays.

O Noteds v0.1.2 leva um marketplace de classificados Nostr ao Android por meio do Tauri. Sua integração com signer Android usa assinatura NIP-55 no Android. O aplicativo publica anúncios e mensagens pelo Nostr e constrói um grafo de busca local com categorias, áreas geográficas e embeddings opcionais no navegador. O código-fonte mais recente corrige o acesso nativo à localização para buscas por proximidade. Ambos os projetos estão em versões iniciais; suas páginas de versão no GitHub não têm notas detalhadas, então essas capacidades vêm dos READMEs com tag e dos commits de implementação.

Statim combina DMs Nostr com outras redes

O Statim v0.4.0 vem depois de sua versão inicial de 23 de setembro. O código-fonte com tag descreve um mensageiro com DMs Nostr via NIP-17 ao lado de XMTP, Status, Telegram e Matrix. As contas partem de uma frase de recuperação mantida localmente; cada conversa identifica seu protocolo, porque essas redes oferecem propriedades de privacidade diferentes. O Android ainda não tem a integração com o Telegram. Essas são as capacidades documentadas do projeto, e não garantias testadas de forma independente nem confirmação de disponibilidade em lojas de aplicativos.

Em desenvolvimento

Amethyst corrige a interoperabilidade de grupos criptografados

O Amethyst é um cliente Nostr para Android com suporte a grupos criptografados Marmot. O White Noise é outro mensageiro Marmot; um lote de interoperabilidade testado com seus clientes trata da administração de grupos, do texto de exclusões e de outros comportamentos expostos quando os dois clientes compartilham uma conversa. Correções mais pontuais enviam reações e exclusões dentro do grupo Marmot, em vez de como mensagens privadas separadas com gift wrap do NIP-17, e aplicam edições feitas em outro cliente após a reinicialização. São merges no código-fonte; os testes descritos nos PRs são mais restritos do que uma versão publicada entre clientes.

Um merge separado de runtime e interface de grupos do Cordn adiciona outro caminho de grupos criptografados por meio de servidores coordenadores. O Cordn é distinto do Marmot, então as duas mudanças não devem ser lidas como uma única migração de transporte.

O Amethyst também incorporou comandos de relay por HTTP em seu relay Geode e no cliente Quartz, sob sua proposta NIP-FE, e uma interface de revisão de conflitos de backup para events substituíveis de perfil e de listas. NIP-FE é terminologia de proposta do projeto; o fluxo de backup permite comparar versões antes de aceitar uma substituição e impede sobrescritas silenciosas do estado local.

O Amethyst também desenvolve o Concord, um protocolo separado de comunidades criptografadas usado pelo Armada e pelo Accordion. Um lote de conformidade adiciona listas de comunidades fragmentadas, provas de fixação, registros de rotação de chaves e de dissolução, seguido de mensagens temporárias e convites diretos. Um convite fica em uma caixa de entrada privada até ser aceito; recebê-lo não contata os relays da comunidade. A mesma mudança corrige uma comparação de autor que podia permitir que a exclusão de outro autor removesse uma mensagem. Correções entre clientes reparam a serialização de rumors não assinados, campos de convite ausentes, a criação de comunidades confirmada pelo relay e a entrada sem reinicialização; os testes em emulador relatados envolveram peers Armada e Accordion ativos.

Uma implementação posterior de canais privados rotaciona as chaves de canal após revogações de acesso relevantes e adiciona controles para criar, tornar privado, tornar público e trocar chaves. Ela também adiciona expulsões cooperativas com verificação de nível hierárquico e faz os anexos das mensagens expirarem junto com as mensagens às quais pertencem. Atualizações WebXDC podem entrar em um buffer de canal separado, mas o Amethyst ainda não tem um host de aplicativos WebXDC. Esse lote posterior relata testes de formato de comunicação e testes unitários, sem uso em dispositivo ou em relay ativo, então o resultado de interoperabilidade anterior não certifica cada controle recém-adicionado.

O motor MLS do Quartz agora preserva segredos de geração de mensagens pulados entre reinicializações, permitindo que mensagens fora de ordem continuem descriptografáveis após a restauração do estado salvo. Quatro epochs anteriores retidas permitem a quem chama autenticar mensagens de aplicação atrasadas, manter seus dados autenticados e impedir que uma geração já consumida seja aberta de novo. Uma atualização da secret tree carrega segredos de nós não expandidos a partir de estado no estilo ts-mls; erros de geração obsoleta específicos por remetente distinguem uma colisão no próprio ratchet de um cliente da repetição feita por outro membro. O PR diz explicitamente que o fallback de epochs retidas já existente no Marmot continua separado, então trata-se de uma capacidade do motor, e não da prova de que todos os caminhos de mensagens do Amethyst a usam.

Uma auditoria dos leitores de tags do Quartz corrige entradas privadas de geohash que podiam ser publicadas em texto claro e um parser que tratava a chave privada de um nsec como chave pública. Ela também corrige endereços de reposts, alvos de ocultação de canais, root tags de salas ao vivo e events endereçáveis de mint. O leitor obsoleto ForkTag foi removido, o que cria uma mudança de API no código-fonte para quem consome o Quartz; linhas de mint já existentes no SQLite ainda precisam de uma migração separada. Modelos de events adicionais cobrem as propostas do Buzz de contêiner de projeto, revisão de artefato e equipe, enquanto modelos de visualização de vídeo e de controle de push criptografado seguem os schemas do Divine; essas adições estabelecem suporte a parsing e construção, e não interfaces de cliente completas nem NIPs numeradas adotadas.

O cliente também renderiza fotografias Ultra HDR no feed e no visualizador em tela cheia no Android 14 ou mais recente. O Android 15 e versões mais novas limitam o aumento de brilho do feed ao dobro da faixa comum, enquanto a tela cheia pode usar toda a faixa da tela; os dispositivos de teste relatados rodavam APIs Android mais novas, deixando o Android 14 e 15 sem teste. Um merge de interface compartilhada e de porta de upload leva 140 telas para código comum entre Android e desktop e tira o trabalho de mídia do Android da thread de interface. Sua auditoria também restaura o relato de erros na remoção de metadados, o que torna a refatoração mais do que uma movimentação de arquivos.

Divine adiciona vídeo criptografado às mensagens diretas

O Divine é um cliente de vídeo Nostr. O NIP-17 transporta mensagens privadas em gift wraps criptografados que ocultam o remetente dos relays. O trabalho de mensagens de vídeo incorporado do Divine criptografa no dispositivo um vídeo anexado, envia o texto cifrado e manda a chave de descriptografia dentro dessa mensagem privada. O destinatário pode verificar e descriptografar o arquivo para reproduzi-lo ou salvá-lo. Uma correção separada de restauração de histórico impede que uma recusa ambígua de um relay encerre prematuramente a recuperação quando outros relays ainda podem responder.

A correção de chaves de moderação aposentadas do Divine recusa chaves aposentadas na resolução de rótulos de moderação e seleciona o destinatário atual de denúncias quando uma denúncia é registrada. Denúncias pendentes endereçadas a uma chave aposentada são redirecionadas para a chave fixada na compilação, e conversas não resolvidas continuam sem permissão de escrita. A mudança também distingue a custódia de chaves aposentadas ao decidir quais conversas históricas um menor pode ler; atualizações de custódia ainda exigem uma nova versão do aplicativo. O tratamento de cache de comentários excluídos impede que um comentário recente excluído com sucesso reapareça quando uma conversa é recarregada.

Para criadores, um modo de gravação com máscara de cor ao vivo mostra o fundo substituto antes de gravar uma tomada, e o mascaramento de parede branca adiciona mascaramento sensível ao brilho por meio do plugin de vídeo. As legendas palavra por palavra preservam os tempos das palavras reconhecidas e usam tempos aproximados quando o servidor fornece apenas cues inteiros. A continuação de stop-motion acrescenta novos quadros no ritmo da composição existente, enquanto o retorno de clipes desanexados, a seleção agrupada de fontes e os presets de velocidade adicionam controles de edição sem mudar o formato dos events Nostr.

O alinhamento da exportação quadrada e sua continuação para clipes menores mantêm textos e stickers no lugar em clipes com resoluções diferentes. A reprodução HLS de terceiros evita uma falha de heap no Android voltando ao início nos limites do loop em vez de pré-carregar playlists importadas repetidas; esses loops podem pausar brevemente a cada reinício. Um recarregamento de preferências da conta mantém os filtros vinculados à conta em seus padrões durante uma troca, ao mesmo tempo que corrige parte de uma asserção de depuração no login. Um problema separado de atualização de rótulos de moderação continua aberto, então o PR não afirma que todos os erros de login foram corrigidos.

Buzz amplia os controles de canal e de identidade de seu relay

O Buzz é um espaço de trabalho baseado em Nostr com relay e clientes próprios. Sua implementação incorporada de artefatos de canal dá a um registro editável um único canal de origem e uma cadeia de revisões; edições conflitantes não podem se tornar ambas a ponta da cadeia. O rótulo NIP-AR do projeto se refere à sua própria proposta e implementação, e não a um padrão Nostr estabelecido.

Para a entrada HTTP protegida, outra mudança incorporada combina uma asserção de identidade federada com a mesma chave comprovada pela autorização do NIP-98. O NIP-98 define events de autenticação HTTP assinados; a asserção NIP-FI do Buzz é uma especificação do projeto. Ele também incorporou criptografia HPKE para envelopes de backup de chaves secretas. Esse PR estabelece trabalho de segurança no código-fonte; a distribuição para todos os clientes continua sem verificação.

O Buzz desktop 0.5.26 inclui o trabalho de artefatos de canal, criptografia HPKE nativa para backups de chaves secretas e um console de administração de relay no desktop. Suas mudanças compartilhadas corrigem solicitações de canais de projeto não listados, sincronizam seções da barra lateral, ordenação, estrelas e silenciamentos entre dispositivos, limitam leituras de conversas longas e reforçam as asserções de identidade do Blossom. As notas de todo o repositório listam à parte o pareamento de identidade do relay, a entrega de menções a companheiros, URLs de push configuráveis, exclusão administrativa atômica e nomes contextuais no celular. Uma versão para desktop estabelece a distribuição desktop e compartilhada; ela não prova que essas mudanças para celular foram distribuídas em uma versão móvel.

A aplicação do NIP-FI em WebSocket do Buzz verifica uma asserção de identidade federada antes de aceitar frames e depois exige que sua chave Nostr corresponda à chave autenticada pelo NIP-42, que comprova a identidade de um cliente para um relay. Uma sessão expira no primeiro que ocorrer entre a expiração do token, a idade máxima da asserção e a duração de conexão configurada; depois da expiração, ela não admite nenhum novo efeito. Esse modo NIP-FI específico do projeto vem desativado por padrão. Commits de áudio já admitidos e a configuração de assinaturas ainda podem ficar esperando uma dependência travada, então a mudança não estabelece um tempo de desconexão limitado universal.

A preparação de exclusão pelo proprietário leva solicitações atestadas pelo operador, por meio de uma aprovação automática vinculada ao inventário, até o executor de exclusão existente. Uma continuação no relay faz com que repetir a mesma solicitação devolva seu estado atual e reserva a cota ativa do proprietário até que a exclusão termine; tombstones de host mantidos permanentemente contam para um limite vitalício de 20 comunidades. São mudanças administrativas no código-fonte, e a continuação orienta os operadores a manter a exclusão desativada até que seu relay e o executor de drenagem estejam ativos. Separadamente, uma auditoria do catálogo de partições detecta partições genéricas e meses sem cobertura antes de criar novas partições de events e de logs de entrega, expondo aos operadores a segurança de serviço e o frescor da auditoria.

O Buzz para celular agora diferencia pessoas e agentes que compartilham um nome de exibição. Seu resolvedor de nomes de identidade qualifica agentes pelo proprietário e adiciona um sufixo curto da chave apenas quando necessário; a integração com conversas usa esses nomes para autores, menções e avisos de associação. Listas, busca e Pulse completam o mesmo comportamento fora de uma conversa. A qualificação visível muda o rótulo local, enquanto uma menção selecionada mantém o nome original da identidade no formato de comunicação.

Conduit avança o checkout após a aceitação pelo relay

O Conduit é um marketplace Nostr que envia mensagens privadas de pedido aos comerciantes. A publicação progressiva em relays distingue a primeira confirmação positiva de um relay da conclusão de todas as tentativas, e uma continuação no checkout persiste essa primeira confirmação antes de prosseguir. A aceitação por um relay significa que o pedido assinado chegou a um relay; ela não prova que um comerciante o leu ou atendeu.

O Conduit também incorporou sessões recuperáveis com signer remoto e negociação transacional de relays do signer. O NIP-46 permite que um aplicativo peça assinaturas a uma chave mantida por um signer separado; essas mudanças preservam o espaço de trabalho da conta do usuário enquanto seu transporte é reparado e depois verificam a conta exata antes de retomar. Os PRs estabelecem comportamento no código-fonte, e não uma versão de checkout distribuída.

O merge de busca de produtos ranqueada do Conduit envia uma consulta comum de busca de texto completo do NIP-50 por produtos de kind 30402 e preserva a ordem de relevância do relay ao longo das verificações de assinatura, da reconciliação de revisões e da filtragem local de elegibilidade. Os cards podem aparecer antes que terminem as leituras em segundo plano do produto exato, enquanto exclusões assinadas mais recentes continuam prevalecendo. Atualizar e Tentar novamente ficam restritos à busca e às leituras do produto exato, sem iniciar uma descoberta ampla do catálogo. Um limite de 100 resultados seguido de filtragem local pode deixar passar correspondências elegíveis, então uma resposta parcial vazia oferece recuperação e não prova que não há produtos.

Elisym constrói um checkout de comércio no Nostr

O Elisym está desenvolvendo um kit de comércio que assina produtos e transporta mensagens privadas de pedidos e recibos pelo Nostr. Seu pacote de comércio incorporado define a verificação de ofertas e events de pedido com gift wrap; uma interface de checkout cuida da revisão da oferta, do pagamento pela carteira e do status de entrega, enquanto um nó de comerciante auto-hospedado empacota o lado da loja. O projeto chama o kind 30490 de provisório e descreve uma fatia mínima para outubro. Esses merges no código-fonte estabelecem uma integração emergente; um padrão de comércio Nostr aceito ou um lançamento público completo não foram demonstrados.

As ferramentas de checkout para agentes do Elisym adicionam buy_product e get_order para seus produtos anunciados no Nostr. A primeira chamada devolve uma cotação sem fazer o pedido, e uma segunda chamada aceita a cotação de uso único e os avisos para o mesmo agente e rede; o estado do pedido é mantido de forma durável no backend de arquivos local do agente. O suporte a checkout com Tempo adiciona um caminho de pagamento por carteira no navegador, com verificação e entrega pelo comerciante. Um hash de transação enviado mantém a tentativa ativa até que seu resultado seja estabelecido, evitando um resultado de não pagamento enquanto uma transmissão ainda pode ser liquidada.

Uma correção posterior do checkout permite que o checkout de produtos assinados inicialize quando uma carteira de navegador se anuncia imediatamente durante a descoberta. A mudança no código-fonte move a declaração da sessão para antes que esse callback possa ser executado; o merge por si só não verifica uma implantação hospedada.

nostter melhora as verificações de signer e a obtenção de events

O nostter é um cliente social Nostr. Sua mudança incorporada de capacidade do signer verifica se há um signer utilizável antes de oferecer ações de follow e de reação. As novas tags de fixação levam a chave do autor e uma dica de relay conhecida sem adivinhar uma, e a ordenação do cache de events substituíveis segue o desempate por timestamp e ID de event do NIP-01. O NIP-01 define as regras centrais dos events Nostr, incluindo como os clientes escolhem entre events substituíveis.

Pensieve prepara a reconciliação isolada de arquivos

O Pensieve é uma ferramenta de arquivamento e recuperação para o Nostr. Seu runtime isolado de negentropy incorporado dá à sincronização um worker limitado e comportamento de conclusão durável. O recurso é opcional, e o PR diz explicitamente que nenhum serviço ou configuração de produção foi ativado; trata-se de uma base para um caminho de recuperação mais seguro, e não de evidência de uma implantação em funcionamento.

ContextVM evita chamadas duplicadas entre relays

O SDK em TypeScript do ContextVM transporta solicitações de ferramentas e recursos como events Nostr. Sua correção incorporada de deduplicação de entrada reconhece uma solicitação em texto simples pelo ID do event mesmo quando vários relays ou uma reconexão a entregam de novo, igualando o caminho existente de mensagens embrulhadas. O PR relata que, antes da correção, uma ferramenta não idempotente era executada três vezes para uma única chamada. Uma mudança complementar de notificações de recursos envia atualizações apenas a clientes inscritos; sessões inicializadas sem assinatura deixam de recebê-las.

Cyberspace revisa as regras de objetos do DECK-0003

O Cyberspace desenvolve o formato DECK-0003 para objetos Nostr estruturados e bags criptografados de regiões, que o Amethyst começou a implementar na edição da semana passada. Novas regras de partes e de objetos ocultos e referências de bags permitem que um bag faça referência a um objeto publicado separadamente em vez de incorporar cada parte. Uma correção posterior diz que uma referência por ID de event não consegue fixar de forma confiável uma versão antiga de um event endereçável, porque um relay pode descartá-la após a substituição. Os leitores devem usar a regra corrigida de referência por coordenada; o texto do merge anterior foi superado.

Wisp corrige respostas a comentários Nostr

O Wisp é um cliente Nostr com recursos de roteamento de relays e de carteira. Depois do suporte a comentários do NIP-22 lançado na semana passada, uma continuação incorporada faz com que a resposta a um comentário NIP-22 também seja um event de comentário, com as referências corretas ao pai e à raiz; o caminho anterior sempre publicava uma nota comum. O NIP-22 permite anexar comentários a muitos tipos de conteúdo Nostr. A correção foi incorporada depois da tag 1.2.5 do Wisp, cujas notas apenas incrementam a versão, então trata-se de progresso no código-fonte cuja distribuição ainda não foi verificada.

Cordn envia as localizações dos coordenadores para um segundo dispositivo

O Cordn coordena mensagens em grupo criptografadas pelo Nostr. Sua mudança incorporada na especificação de múltiplos dispositivos leva as dicas de relay do coordenador de um grupo no documento de grupo replicado. Um dispositivo recém-semeado pode então encontrar um coordenador ausente dos relays padrão, em vez de parecer entrar em um grupo cujo histórico pendente e mensagens ao vivo ele não consegue obter. Trata-se de trabalho no documento de protocolo, na sequência da versão de fila offline do Cordn da semana passada, e não de uma nova versão do cliente.

Nostr Atlas abre um diretório de identidades verificáveis

O Nostr Atlas é um novo diretório que apresenta perfis Nostr ao lado de reivindicações de contas externas. Sua publicação incorporada do site separa o diretório da demonstração de componentes do projeto, e o site responde publicamente. Um merge do fluxo de reivindicação permite que o dono de uma conta no X publique uma prova NIP-39 assinada com um signer de navegador, enquanto o enriquecimento de perfis lê os metadados Nostr de kind 0 apenas depois que a prova é verificada. O NIP-39 define o padrão de prova para associar uma chave Nostr a outra identidade online; uma confirmação de relay, por si só, não marca uma reivindicação como verificada.

nostr-java adiciona ferramentas de hospedagem de mídia e preserva as posições das tags

O nostr-java é uma biblioteca Java e um conjunto de ferramentas MCP para aplicativos Nostr. Suas ferramentas Blossom incorporadas permitem fazer upload, encontrar, listar e excluir mídia endereçada por hash e gerenciar a lista de servidores do usuário. Uma correção de publicação separada mantém no lugar os valores vazios de tags: as tags Nostr são posicionais, então descartar uma dica de relay vazia podia deslocar um marcador para o campo errado e fazer o event publicado diferir da prévia aprovada.

Zap Cooking muda a forma de recuperar o histórico da conta

O Zap Cooking é um cliente Nostr para compartilhar receitas. Seu trabalho de recuperação Lazarus incorporado substitui um backup construído sobre events de dados específicos de aplicativo do NIP-78 por uma abordagem que examina as versões de events substituíveis retidas pelos relays para detectar follows, silenciamentos ou perfis sobrescritos. O Lazarus continua sendo um protocolo em rascunho; a recuperação depende de relays que tenham retido as versões antigas, e um PR incorporado em um cliente web não garante que todo event perdido possa ser recuperado.

O cliente também incorporou controles opcionais de prova de trabalho NIP-13 para notas e respostas e um modelo de anexos que mantém a ordem das mídias e as descrições do NIP-92 consistentes entre a prévia e a publicação. O NIP-13 permite que um remetente gaste computação local em um event antes de publicá-lo; o NIP-92 transporta metadados de mídia como tags do event.

A correção de reivindicação de NIP-05 do Zap Cooking exige autorização NIP-98 sobre o corpo exato da solicitação e rejeita um signer diferente da chave pública que reivindica o nome. Antes, esse endpoint público aceitava reivindicações não autenticadas que podiam substituir o nome de outro membro. O nível de assinatura agora vem do registro de associação existente, e usuários de signer remoto recebem um pedido de assinatura ao reivindicar. O caminho separado e confiável de registro no servidor permanece inalterado.

Um reparo da lista de silenciados impede que as ações de silenciar em perfis substituam toda a lista de kind 10000 apenas por tags de chave pública. O caminho anterior apagava entradas de palavras, hashtags e conversas, além do conteúdo criptografado, e uma das telas podia republicar publicamente chaves de silenciamento privadas já descriptografadas. O novo caminho lê a cópia do relay, preserva tags não relacionadas e o texto cifrado e se recusa a publicar quando essa leitura não está disponível. Remover um silenciamento privado exige descriptografar e recriptografar pelo signer.

Opal traz assinatura remota ao Omarchy

O Opal é um signer Nostr para desktop feito para o ambiente Linux Omarchy. Sua versão 0.3.3, de 28 de setembro, dá sequência à primeira série pública com suporte à assinatura remota do NIP-46, um chaveiro local e uma interface de permissões para solicitações de aplicativos conectados. O NIP-46 mantém a chave da conta com o signer enquanto um cliente separado pede a ele que aprove operações. Esta é uma versão inicial de um signer específico de plataforma, e não uma afirmação de suporte mais amplo para desktop.

WatchTower abre um painel de controle de relays NIP-86

O WatchTower é um painel recém-publicado para administração de relays por meio do NIP-86, o protocolo de solicitações autenticadas de gerenciamento de relays. Uma instância pública responde, oferecendo aos operadores um lugar para inspecionar a interface. O repositório foi criado em 22 de setembro; um site acessível não estabelece que seus fluxos de autorização tenham sido auditados de forma independente nem que ele funcione com todas as implementações de relay.

Hubstr Blossom abre uma origem pessoal de mídia

O recém-publicado servidor Hubstr Blossom permite que um cliente Nostr faça upload de imagens, vídeos e arquivos para um endpoint Blossom auto-hospedado e depois coloque essas URLs em events. Seu README documenta armazenamento local por hash de conteúdo, um índice SQLite, autorização assinada de kind 24242 para alterações e uma série de operações Blossom para upload, espelhamento, listagens e exclusão. Leituras públicas permitem que outros clientes renderizem a mídia publicada sem receber direitos de upload.

As opções documentadas do servidor também extraem metadados de arquivos para events do NIP-94, que descrevem mídia compartilhada. O servidor pode recodificar imagens sem metadados EXIF e, por padrão, protege solicitações de espelhamento contra alvos em redes privadas. Trata-se de uma implementação recém-publicada com instruções de implantação, e não de evidência de uma adoção ampla em produção.

O Hubstr Relay publicou seu código-fonte inicial em 24 de setembro. Ele combina um cache pessoal de events em SQLite com um relay público: leitores não autenticados veem os events públicos permitidos, enquanto inquilinos autenticados via NIP-42 podem ler seu cache. Gift wraps do NIP-17 continuam indisponíveis para leitores convidados. Sua atualização de 25 de setembro corrige os registros devolvidos pelos métodos de listas de pubkeys do NIP-86.

Meshstr experimenta uma malha de relays sem permissão

O Meshstr é um design em fase alpha para que relays Nostr negociem orçamentos entre peers e troquem recibos de uso assinados. Sua primeira implementação inclui uma ponte de política de escrita para o strfry, um relay Nostr, adicionada em 27 de setembro, com uma correção de socket no dia seguinte. O repositório descreve negociação DIDComm e reconciliação NIP-77, que permite a peers comparar conjuntos de events sem trocar seus inventários completos, ao lado de relatórios verificáveis de peers que excedem os orçamentos combinados.

Essas regras do projeto são uma proposta, e não um NIP adotado nem uma rede pública de relays demonstrada. O progresso concreto desta semana é o caminho de código publicado que conecta a política de escrita de um relay à contabilidade proposta para a malha.

Dossier mostra o que um histórico público no Nostr pode revelar

O Dossier é uma nova ferramenta de autoauditoria, executada no navegador, para a pegada de uma pessoa no Nostr e no Lightning, com uma demonstração pública. Ele reúne links de perfil visíveis, rastros de zaps, horários de postagem, metadados de antigas mensagens diretas criptografadas do NIP-04 e metadados de mídia, como o EXIF de fotos; ele também pode mostrar onde um relay ainda serve um event que alguém tentou excluir. O suporte a signers NIP-07 permite que o usuário autorize ações de limpeza sem colar uma chave privada na página.

Os limites documentados do projeto importam: uma varredura só vê os relays que alcança, e um pedido de exclusão não consegue apagar cópias mantidas em outros lugares. O repositório apareceu em 27 de setembro e não tem versão com tag; a demonstração e o código-fonte estabelecem uma ferramenta inicial, e não um inventário completo da atividade passada de alguém.

Marmot MDK amplia enquetes, emojis personalizados e metadados de conta

O Marmot MDK fornece o runtime e os bindings para mensagens em grupo criptografadas no Nostr. Merges posteriores no código-fonte do MDK expõem seleções de enquete paginadas por votante, usando as mesmas regras de resposta efetiva das contagens agregadas. Componentes de grupo opcionais pertencentes ao aplicativo dão aos hosts configurações controladas pelo administrador que sobrevivem à retenção de mensagens e chegam aos recém-chegados em seu Welcome. Envios com tags e reações com mídia levam metadados de emojis personalizados pelo runtime e pelos bindings, mantêm o material de descriptografia de imagens de reação anexadas após uma mudança de epoch e rejeitam tags de anexo forjadas. Essa mudança amplia a estrutura C de solicitação de upload, então quem consome a interface C precisa recompilar contra o header.

Uma correção de convergência mantém as mensagens pendentes quando nenhuma branch canônica foi selecionada, em vez de invalidá-las sem testar o estado ativo. Uma limpeza de caminho inalcançável que a acompanha encaminha commits preparados não resolvidos para o comportamento de nova tentativa retido. As leituras de mídia criptografada alinham o tempo limite de leitura HTTP ao tratamento de inatividade de corpos retomáveis, atacando transferências grandes travadas sem afirmar que o teste de aceitação em dispositivo do APK recebido, ainda pendente, passou. Marcadores de etapas de inicialização mostram qual etapa de abertura da conta expirou, adicionando evidência de diagnóstico sem afirmar que a trava de inicialização subjacente foi resolvida.

O conector local de agentes também mescla os metadados de perfil existentes ao publicar uma atualização de kind 0, preservando campos que a solicitação omitiu. As atualizações de perfil de grupo expõem mudanças no nome e na descrição de um grupo pelo caminho existente autorizado pelo administrador atual. Sua autenticação por socket ainda concede acesso a toda a API local; este merge não adiciona concessões de capacidade por principal. Essas mudanças no código-fonte vêm depois da versão 0.11.0 com tag.

rust-nostr correlaciona as respostas de contagem dos relays

O rust-nostr, uma biblioteca e SDK em Rust para aplicativos Nostr, incorporou respostas COUNT correlacionadas e erros de espera mais claros. O SDK se inscreve antes de enviar o COUNT e aceita apenas a resposta correspondente, evitando que um receptor perdido ou fechado pareça um zero legítimo. Ele também preserva os erros do receptor para confirmações de publicação e autenticação de relay, de modo que quem chama pode distinguir uma confirmação ausente de uma rejeição explícita. As assinaturas dos métodos públicos permanecem inalteradas.

ZapTracker adiciona métricas da rede Nostr e de citações

O ZapTracker é um painel para criadores acompanharem engajamento no Nostr e atividade de carteira. Um merge do painel de rede substitui estatísticas da rede Lightning por dados de relays Nostr online vindos do nostr.watch e por informações de capacidades vindas de documentos NIP-11. Uma mudança de métricas de citações conta events de kind 1 que carregam tags q, ao lado de curtidas, reposts, favoritos e zaps. Isso permite que criadores vejam citações nos rankings de conteúdo e nos gráficos de engajamento; continua sendo evidência de código-fonte incorporado.

LaWallet NWC encaminha recargas de cartão para a carteira do cartão

O LaWallet NWC conecta carteiras Lightning a aplicativos via Nostr Wallet Connect. Seu merge de recarga do BoltCard anuncia um link de pagamento LUD-19 que cria uma fatura pelo método NWC make_invoice da carteira do cartão. Cartões bloqueados, desativados ou não pareados não anunciam link de pagamento, e o caminho não redireciona recargas para o endereço Lightning separado do proprietário. Uma continuação expõe o mesmo link no emulador e leva notas do pagador aceitas pelo destinatário em envios LNURL.

Um novo relay khatru expõe controles de moderação ao proprietário

O nostr-relay-khatru publicou seu código-fonte inicial em 29 de setembro como um relay de uso geral derivado da implementação específica do HiveScope, descontinuada. A instância pública serve um documento NIP-11 que nomeia este repositório e anuncia autenticação, expiração de events, events protegidos, contagem, reconciliação e administração de relay. Uma implementação de 30 de setembro adiciona controles de moderação ao painel do proprietário. Os metadados públicos verificam um endpoint implantado, e não o teste bem-sucedido de cada método anunciado.

Um construtor local de web of trust acompanha unfollows

O etemiz/wot publicou em 30 de setembro um crawler de web of trust para o Nostr. Ele lê listas de follows e listas de relays do NIP-65, calcula a confiança a partir de raízes configuráveis e grava as pontuações em LMDB para políticas de relay, feeds e filtros de spam. A documentação do projeto explica o compromisso: atualizações ao vivo aumentam a confiança, enquanto varreduras completas agendadas aplicam reduções e unfollows. As pontuações dependem das raízes escolhidas. É código-fonte recém-publicado, sem versão com tag nem afirmação de implantação em produção.

Moyu abre um cliente de espaço de trabalho Marmot

O Moyu publicou o código-fonte de um cliente de chat para espaços de trabalho em Rust construído sobre o Marmot, com interfaces de linha de comando, terminal e desktop. Suas mudanças de 30 de setembro usam mudanças de associação registradas localmente para impedir que pedidos de entrada antigos readmitam membros removidos, fazem os códigos de convite expirarem após sete dias e permitem que administradores os revoguem. A saída do terminal filtra caracteres de controle e substituições de direção de texto fornecidos por outros membros. Um fork fixado do MDK encaminha as transferências de anexos Blossom pelo proxy SOCKS5 configurado, com a resolução de nomes de host feita por esse proxy. As mudanças da 0.3.0 estão no código-fonte público; ainda não há tag de versão pública nem entrada de lançamento.

Trabalho em protocolos e especificações

NIP-39 estende as provas de identidade ao Bluesky e ao Discord

O NIP-39 permite que uma conta Nostr aponte para a prova de que controla uma identidade em outra plataforma. Uma mudança incorporada em 27 de setembro dá às novas provas uma frase recomendada e orienta os verificadores a aceitar provas mais antigas que contenham o npub da conta, mesmo quando a redação é diferente. Ela também documenta postagens no Bluesky e mensagens no Discord como locais de prova. Uma reivindicação no Discord só pode ser verificada por alguém que consiga ler o servidor onde a mensagem foi publicada.

NIP-86 adiciona gerenciamento de códigos de convite para administradores de relays

O Compass descreveu na edição de 8 de julho a proposta de convites do NIP-86 enquanto ela estava aberta; agora ela foi incorporada. O NIP-86 define uma API padrão de gerenciamento de relays, e o NIP-43 define como relays restritos anunciam a associação e processam pedidos de admissão. O merge de 24 de setembro adiciona listclaims, createclaim e deleteclaim para que um administrador possa listar, emitir e revogar códigos de convite aceitos por um relay. Isso dá aos operadores um caminho de gerenciamento para convites que podem conceder um papel a um membro depois que ele entra; não obriga todos os relays a oferecer os métodos.

Uma correção à cobertura do NIP-86 da semana passada: a especificação incorporada adicionou unallowevent, unbanevent, listallowedevents e listdisallowedkinds. O item anterior listava nomes de uma descrição desatualizada da proposta. Os dois primeiros métodos revertem uma decisão de permissão ou banimento no nível do event; os outros inspecionam events permitidos e kinds não permitidos.

NIP-51 move os conjuntos de follows favoritos para um kind de event não utilizado

O NIP-51 define listas públicas e privadas, incluindo uma lista dos conjuntos de follows favoritos de um usuário. O Compass descreveu a proposta de colisão de kinds na edição de 22 de julho; agora ela foi incorporada. A correção de 27 de setembro atribui a essa lista de favoritos o kind 10021, porque o número anterior já estava em uso. Suas tags a continuam apontando para conjuntos de follows de kind 30000. A mudança resolve uma colisão de números na especificação; ela não cria uma nova forma de seguir pessoas.

NIP-51 propõe respostas ocultas para cada conversa

Uma proposta aberta para o NIP-51 permitiria que o autor de uma conversa publicasse um conjunto público de respostas ocultas, que clientes cooperativos exibiriam atrás de um botão. Ela usa um event endereçável de kind 30027 por conversa, com o ID da raiz como tag d e tags e nomeando as respostas; só vale um conjunto assinado pelo autor da raiz. Listar a raiz pede aos clientes que ocultem as respostas de outros autores e deixem de oferecer um campo de resposta, embora as respostas ainda possam ser publicadas nos relays. O formato por conversa limita colisões de edição à mesma conversa. O autor relata uma implementação no Nostrich, mas a inspeção do código-fonte público não a confirmou; a proposta continua sem merge, e o formato do conjunto ainda está em discussão.

NIP-DB propõe nomes de domínio verificados para serviços endereçados por chave

A proposta aberta NIP-DB, enviada em 28 de setembro, descreve events Nostr que vinculam um domínio comum da internet à chave que o serve em uma rede endereçada por chave, como o FIPS, uma malha criptografada que endereça nós por chave pública Nostr. O dono de um domínio pode estabelecer o vínculo com um registro DNS TXT ou com uma prova DNSSEC transportada junto com a reivindicação; os clientes fixariam um resultado verificado para uso offline posterior. A proposta proíbe explicitamente a resolução por meio de uma reivindicação não verificada, já que qualquer pessoa pode reivindicar o domínio de outra em um event Nostr. O fips-pub-domains é a implementação de referência do autor, mas os números dos kinds de event e parte do texto específico da rede sobreposta ainda estão em revisão. Os testes de ponta a ponta relatados são evidência do autor, e não uma afirmação de que a proposta seja um NIP aceito.

Um rascunho de feed privado explora grupos criptografados de destinatários

Uma nova proposta de envelope para múltiplos destinatários, aberta em 29 de setembro, esboça notas, respostas e conexões privadas cujos destinatários pretendidos conseguem encontrar um event sem expor suas chaves públicas comuns nas tags visíveis. Ela propõe tags de alias opacas por par, derivadas de segredos compartilhados, e kinds de event provisórios, incluindo uma forma de embrulhar outro event Nostr para centenas de leitores. Isso poderia dar a pequenos feeds privados um caminho de obtenção mais direto do que enviar uma mensagem separada a cada membro.

O autor da proposta a chama explicitamente de trabalho em andamento. O rascunho não tem implementação demonstrada nem revisão de segurança, e suas atribuições de kinds e regras de assinatura no nível de bytes continuam em aberto.

Uma proposta para o Blossom permite que outras pessoas anunciem mídia espelhada

Uma proposta aberta de NIP descreve uma forma de quem espelha o blob Blossom de outro autor anunciar essa cópia pelo Nostr. Um cliente poderia então procurar a cópia se o servidor original perder o blob. A discussão também levantou a verificação da lista atual de servidores BUD-03 de quem espelha quando a dica de servidor anunciada fica desatualizada. Trata-se de um caminho de descoberta proposto, e não de uma garantia de que clientes ou relays de arquivamento já oferecem armazenamento alternativo.

Relatos de eventos nas estradas buscam um formato Nostr comum

A proposta aberta Road Event Reports descreve relatos e confirmações de buracos, interdições, radares e outras condições das estradas. Ela usa tags de localização e o timestamp de expiração do NIP-40, que indica aos relays quando parar de servir um event, para que um relato não precise continuar vigente indefinidamente. O autor baseou as revisões em uma amostra de events recuperados de relays públicos e nos clientes Roadstr existentes para relatar condições das estradas, mas o rascunho ainda deixa em aberto uma questão de codificação compacta, e o número de NIP proposto não foi adotado.

Marmot revisita a coordenação entre múltiplos dispositivos

O redesenho de múltiplos dispositivos do Marmot substitui um rascunho de External Commit nunca implementado por um roteiro não normativo para receber feedback inicial. A nova direção explora um dispositivo existente aprovando um novo, levando-o às conversas e mais tarde removendo dispositivos, enquanto mantém visíveis as questões em aberto. Os IDs reservados pelo rascunho removido são liberados porque nenhuma implementação os adotou. O documento de ideias não aloca novos IDs nem formatos de comunicação e não é um recurso de múltiplos dispositivos implementado.

Seis anos de setembros do Nostr

A última edição de setembro é uma oportunidade de acompanhar como o Nostr passou de esboços a um conjunto maior de ferramentas interoperáveis. Um protótipo de carona de 2021 usava events assinados para coordenar um serviço; cinco anos depois, a redação das provas de identidade e as colisões de kinds de listas são o tipo de detalhe que os mantenedores estão resolvendo. Nesse intervalo, os clientes aprenderam a apresentar conversas, mídia e recuperação de formas que pessoas comuns conseguem usar. As fontes datadas abaixo mostram etapas dessa progressão. Elas não estabelecem que todo experimento foi lançado nem que cada design antigo continua recomendado.

Setembro de 2021: primeiros experimentos com formatos úteis

Um commit do BUber de 4 de setembro explorou um conceito de pareamento de táxis usando events Nostr. Ele mostrou como uma solicitação assinada e transportada por relays podia coordenar pessoas sem atribuir o serviço inteiro a um único servidor. A fonte é um conceito e não estabelece um serviço de corridas lançado.

Mais tarde naquele mês, o código-fonte do Loquaz de 23 de setembro ofereceu um protótipo de chat para desktop. Foi outra tentativa inicial de fazer as mensagens de relay parecerem um aplicativo comum. A fonte não estabelece criptografia de ponta a ponta concluída nem um mensageiro em produção; o fio duradouro é a busca por uma interface de conversa utilizável sobre events simples. O BUber testou o pareamento de corridas, e o Loquaz testou o chat; ambos usaram events assinados antes que os padrões comuns de cliente se consolidassem. Esses ensaios delinearam dois problemas recorrentes para os clientes posteriores: coordenar por meio de relays e apresentar events como uma conversa utilizável.

Setembro de 2022: chat e ações delegadas entram nas especificações

A mudança no NIP-28 de 10 de setembro descreveu canais de chat públicos com mensagens e metadados que os clientes podiam interpretar em conjunto. O NIP-28 tornou uma sala compartilhada um assunto explícito do protocolo e deu aos clientes uma convenção comum de canais.

Em 23 de setembro, o NIP-26, em seu texto de assinatura delegada, documentou uma forma de uma chave autorizar outra a assinar events limitados. Ele capturou uma questão de design importante de 2022: como usar uma identidade Nostr sem entregar a chave principal a cada aplicativo. O NIP-26 agora está marcado como não recomendado, então este é o registro de um experimento, e não um conselho para novas integrações. Seu status posterior mostra como o modelo de assinatura evoluiu: uma especificação pode preservar a formulação útil de um problema mesmo quando a resposta proposta é aposentada.

Setembro de 2023: os clientes amadurecem em torno da descoberta de relays e dos metadados

O Damus é um cliente social Nostr. Seu changelog de 21 de setembro registrou trabalho em seu banco de dados Nostr local, na busca e na navegação por hashtags. Essas mudanças tornaram um feed social movimentado mais fácil de navegar e de recuperar em um celular; o changelog datado é evidência daquela versão do cliente, e não de todas as capacidades posteriores do Damus.

Os detalhes do protocolo também avançavam. Uma mudança de 26 de setembro no NIP-24 esclareceu campos opcionais de metadados de perfil, enquanto a mudança de 29 de setembro no NIP-65 tratou da normalização e da deduplicação de URIs de relays. O NIP-65 diz aos clientes como publicar os relays que usam para leitura e escrita; um tratamento consistente das URIs ajuda essas listas a apontar para o mesmo relay mesmo quando as strings diferem de formas inofensivas. Essa pequena convenção levou o design de clientes em direção a uma descoberta confiável: encontrar os events de uma pessoa depende de saber onde eles são publicados.

Setembro de 2024: as postagens ganham contexto mais rico

As notas de lançamento do Damus de 22 de setembro descreveram suporte a destaques e comentários do NIP-84. O NIP-84 dá aos leitores uma forma de citar e discutir um trecho de material de formato longo. O trabalho no cliente mostra como uma ideia de protocolo se tornou algo que as pessoas podiam usar durante a leitura.

Enquanto isso, o NIP-34 recebeu uma mudança em 20 de setembro que refinou assuntos e rótulos de issues para colaboração Git pelo Nostr, e o NIP-73 recebeu uma mudança no mesmo dia que refinou identificadores de conteúdo externo. São mudanças de especificação separadas: uma ajuda as issues de um repositório a manter sua estrutura, enquanto a outra permite que um event se refira a material fora do Nostr. Ambas ampliam o significado que um cliente consegue preservar quando o conteúdo circula entre comunidades, repositórios e outras mídias.

Setembro de 2025: controles de acesso e contexto de pagamento ficam mais precisos

Uma revisão do NIP-42 de 6 de setembro tratou da autenticação de relays com múltiplos usuários. O NIP-42 permite que um relay desafie um cliente a provar qual chave Nostr está fazendo uma solicitação; a atualização importava para serviços que atendem mais de uma conta autenticada pela mesma conexão.

Uma atualização do NIP-47 de 15 de setembro adicionou metadados de pagamento opcionais às solicitações do Nostr Wallet Connect. O NIP-47 permite que um aplicativo peça a uma carteira para executar ações pelo Nostr. Mais contexto pode tornar uma interação com a carteira compreensível, mas os metadados podem expor detalhes de quem paga, então clientes e carteiras ainda precisam tratá-los como sensíveis. A mudança ilustra como o trabalho de interoperabilidade passou a incluir o que um destinatário pode descobrir, e não apenas se uma solicitação pode ser entregue.

Setembro de 2026: detalhes de interoperabilidade encontram a identidade pública

Neste setembro, uma mudança incorporada no NIP-51 afastou o kind de event dos conjuntos de follows de uma colisão. O NIP-51 define listas que uma pessoa pode manter e compartilhar; kinds de event exclusivos permitem que os clientes distingam um tipo de lista de outro. Uma edição anterior do Compass discutiu a proposta, enquanto o merge de setembro é a mudança de status.

Uma segunda mudança incorporada no NIP-39 esclareceu o texto das provas e adicionou mais formas de associar uma conta externa a uma identidade Nostr. O NIP-39 trata de reivindicações de identidade verificáveis, e não de um registro central de identidades. Juntos, os dois merges mostram o trabalho atual de protocolo concentrado nos pequenos detalhes que determinam se clientes independentes interpretam corretamente os mesmos events de identidade e de listas. Eles também mostram uma mudança da invenção de novas categorias de events para a redução da ambiguidade nas existentes.

Ao longo desses seis setembros, o padrão é uma progressão: de provar que um event assinado pode descrever uma solicitação de aplicativo a perguntar como um cliente verifica uma reivindicação sobre uma pessoa. Os protótipos antigos importam porque expõem as questões que especificações e clientes posteriores tiveram de responder: quem assina, onde um event é encontrado, o que ele significa e como alguém sabe se deve confiar nele. É também por isso que uma correção de protocolo pequena e precisa pode importar tanto quanto uma nova interface.