Nostr Wallet Connect

Anna ouve um podcast e quer enviar uma pequena quantia ao autor pela Lightning Network. Com NWC, o leitor pode pedir diretamente o pagamento à carteira. O serviço verifica os direitos da ligação antes de executar um pedido autorizado. O NWC não determina quem guarda as chaves dos bitcoins: do outro lado pode estar o nó da própria Anna ou um serviço que guarda fundos por ela. O mesmo botão «Ligar carteira» pode, por isso, representar níveis de controlo muito diferentes. Dependendo dos direitos concedidos, a aplicação também pode agir sem nova confirmação para cada pagamento. [1] [2]

A carteira costuma fornecer um código QR ou uma cadeia de ligação, tecnicamente uma URI. Contém a chave pública do serviço, o endereço do relay e secret, a chave privada dessa ligação cliente. Não é o seed da carteira, o seu valor secreto inicial, nem a sua Seed Phrase, as palavras de recuperação. Ainda assim, não é um simples endereço público: quem obtiver uma cópia utilizável pode exercer as mesmas permissões. O dano possível depende das funções e limites autorizados. Ligações separadas para aplicações diferentes permitem identificá-las e revogá-las individualmente, reduzindo também as possibilidades de associação entre elas. [1]

Uma aplicação pode precisar apenas de consultar o saldo ou também de enviar dinheiro. São permissões distintas. O evento público info anuncia as capacidades do serviço; get_info devolve os métodos disponíveis para uma ligação concreta. Um método é um comando com nome: pay_invoice pede um pagamento, make_invoice cria um pedido de pagamento, lookup_invoice consulta o seu estado e get_balance lê o saldo. O próprio get_info também integra o conjunto básico. O histórico, keysend — pagamento sem uma fatura previamente criada — e as notificações são extensões opcionais. Um comando existir no servidor não autoriza todas as aplicações ligadas a usá-lo. [1] [3] [5]

Anna pode querer atribuir ao leitor apenas um orçamento limitado. Se o serviço oferecer limites de despesa, de métodos ou de validade, tem de os fazer cumprir. Um número mostrado apenas no leitor não protege contra uma aplicação que envie um pedido diferente. Verifique ainda se o orçamento é único ou renovável e como são contabilizadas as taxas. Quando Anna deixar de usar a aplicação, deve revogar os seus direitos no serviço da carteira. Apagar a aplicação ou a ligação local não demonstra que o acesso foi retirado. A revogação bloqueia pedidos futuros, mas não desfaz um pagamento concluído. [1]

Uma fatura Lightning é um pedido de pagamento, por exemplo no formato BOLT11, não uma prova de pagamento. O NIP-47 expressa montantes e taxas em msat, milésimos de satoshi: 1000 msat = 1 sat. Confundir as unidades altera o valor por um fator de mil. make_invoice apenas cria o pedido. Um pay_invoice bem-sucedido devolve preimage. A partir desse valor calcula-se o hash, um valor curto de verificação. Tem de corresponder ao hash de pagamento da fatura; a preimage devolvida serve assim de prova da conclusão do pagamento. Uma resposta de erro usa error. O estado pode ser consultado com lookup_invoice. A aplicação deve tratar o resultado real, não anunciar sucesso só porque enviou uma mensagem. [1]

Anna toca em Pagar, mas a aplicação não recebe resposta. Um timeout, o fim do tempo de espera, não esclarece o que aconteceu ao dinheiro. O NWC usa eventos efémeros para pedidos e respostas; um relay desligado ou um serviço indisponível pode fazer perder uma mensagem. Mas pode ter desaparecido apenas a resposta a um pagamento já concluído. Primeiro consulte o estado com lookup_invoice ou na carteira. O silêncio não confirma uma falha. Um novo pedido não é automaticamente uma repetição segura da ação anterior; é preciso apurar primeiro o resultado. [1]

Aplicação e carteira trocam mensagens encriptadas. A negociação atual dá preferência a nip44_v2; o obsoleto nip04 mantém-se por compatibilidade. A ausência da etiqueta encryption significa o modo antigo. O NIP-44 não fornece forward secrecy, proteção da comunicação passada caso uma chave duradoura seja comprometida mais tarde. Um relay também pode ver tipos de eventos, etiquetas, chaves públicas de ligação e horários. Por isso, o NWC não deve usar a chave principal com que a pessoa publica no Nostr. Chaves separadas ajudam a reduzir a associação entre pagamentos e perfil público, mas não garantem anonimato completo. [1] [4]

Não é necessário memorizar os números das mensagens para usar o sistema, mas eles importam ao desenvolver uma integração. Info usa kind 13194, os pedidos 23194 e as respostas 23195. kind identifica o tipo de evento. A etiqueta p indica a contraparte e a etiqueta e da resposta aponta para o pedido original. O cliente verifica a assinatura, a chave esperada do serviço, essa associação e result_type, o comando a que pertence o resultado. Não basta aceitar qualquer mensagem do relay como confirmação. Caso contrário, uma resposta alheia ou relativa a outra ação poderia passar pelo resultado deste pagamento. [1]