Nostr WoT SDK estabiliza recuperação com passkey e assinatura do provedor

Passkeys derivadas e armazenadas são sistemas diferentes

O pacote de identidade reconhece dois modos. No modo derivado, a chave privada Nostr é calculada de forma determinística a partir da saída PRF do WebAuthn. No modo armazenado, essa saída protege uma chave privada existente, uma seed ou um vault com várias contas.

Novas credenciais carregam um identificador marcado que declara o modo antes da leitura do armazenamento. Uma credencial armazenada nunca é interpretada silenciosamente como derivada. Se uma credencial antiga sem marca não tiver evidência suficiente, resolvePasskeyIdentity retorna ambiguous e uma chave pública candidata. A aplicação precisa mostrar essa chave e pedir confirmação antes de derivar o segredo.

Essa separação preserva a continuidade da identidade. O modo derivado vincula a identidade ao cálculo da passkey. O modo armazenado permite proteger novamente a mesma identidade sob outro relying party, desde que o host importe e criptografe o conteúdo de forma deliberada.

A recuperação continua sob controle do host

@nostr-wot/identity/vault fornece criptografia portátil, validação de registros e orquestração. Ele não chama autenticadores nem abre conexões com relays. O host fornece WebAuthn ou o cliente nativo, transporte, assinatura e verificação de eventos e a interface de consentimento.

Um registro pode conter uma chave ou um vault com várias contas. A criptografia autentica o tipo, o ID do relying party, o autor e o ID da credencial. Antes de gravar, o provedor precisa inspecionar o armazenamento existente. Qualquer blob não vazio exige confirmação para ser substituído, inclusive quando não pode ser decodificado. Uma falha ou recusa não muda automaticamente para relays.

O uso de relays também é explícito. O host deve permitir essa opção, escolher os relays e receber ao menos uma confirmação. Novos registros usam o kind provisório 31778, ainda não reservado por um NIP. Formatos anteriores continuam legíveis. Uma gravação local, a confirmação de um relay ou a resposta de um provedor comprova apenas aquela operação, não a restauração em outro dispositivo.

Duas formas de integrar contas Nosskey existentes

nostr-wot-sdk 3.0.1 lê backups Nosskey explícitos em modo de chave direta ou chave encapsulada com NIP-44, preservando as entradas PRF originais. A chave pública recuperada é comparada com o backup e o leitor não tenta outro modo quando faltam evidências.

Aplicações que não querem importar a chave privada podem usar NosskeyIframeSigner. Ele fixa a janela do iframe, a origem HTTPS e a conta selecionada, verifica o conteúdo e as assinaturas dos eventos, limita o tempo das solicitações e exige encerramento explícito. Consentimento do provedor e suporte do navegador continuam sendo requisitos externos.

O que muda para os integradores

Os pacotes estáveis podem ser instalados sem a tag de pré-lançamento:

npm install @nostr-wot/identity@1.1.0 nostr-wot-sdk@3.0.1 nostr-tools

O host ainda precisa testar autenticadores e sincronização em dispositivos reais. Também deve preservar campos desconhecidos ao regravar um vault, limpar buffers de segredos, confirmar a chave pública durante migrações e informar onde a recuperação está armazenada. Registros são snapshots e precisam de uma política de atualização após mudanças nas contas.

As tags estáveis tornam as APIs testadas instaláveis sem next. Elas não transformam passkeys em um backup universal. Autorizar um relying party é uma decisão de confiança, o kind provisório pode evoluir e cada aplicação continua responsável por consentimento, durabilidade e uma recuperação verificável.