• Exemplo
• Encontrando usuários a partir do identificador NIP-05
• Notas
• Identificação, não verificação
• Sugestão de implementação para descoberta de usuários
• Clientes devem sempre seguir chaves públicas, não endereços NIP-05
• Chaves públicas devem estar em formato hexadecimal
• Exibindo apenas o domínio como identificador
• Justificativa para o formato /.well-known/nostr.json?name=<local-part>
• Permitindo acesso a partir de aplicações JavaScript
• Restrições de segurança

Mapeamento de chaves Nostr para identificadores de internet baseados em DNS

final optional

Em eventos do tipo 0 (user metadata), é possível especificar a chave "nip05" com um identificador de internet (um endereço no formato de e-mail) como valor. Embora exista um link acima para uma especificação muito liberal de “identificador de internet”, o NIP-05 assume que a parte <local-part> será restrita aos caracteres a-z0-9-_., sem diferenciar maiúsculas de minúsculas.

Ao encontrar isso, o cliente divide o identificador em <local-part> e <domain> e usa esses valores para fazer uma requisição GET para:

https://<domain>/.well-known/nostr.json?name=<local-part>

O resultado deve ser um documento JSON contendo uma chave "names", que deve ser um mapeamento de nomes para chaves públicas em formato hexadecimal. Se a chave pública associada ao <name> corresponder à pubkey do evento de user metadata, então o cliente conclui que aquela chave pública pode de fato ser referenciada por esse identificador.

§Exemplo

Se um cliente encontrar um evento como este:

{
  "pubkey": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9",
  "kind": 0,
  "content": "{\"name\": \"bob\", \"nip05\": \"bob@example.com\"}"
  // outros campos...
}

Ele fará uma requisição GET para:

https://example.com/.well-known/nostr.json?name=bob

E receberá uma resposta como:

{
  "names": {
    "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
  }
}

Ou com o atributo recomendado "relays":

{
  "names": {
    "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
  },
  "relays": {
    "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": [
      "wss://relay.example.com",
      "wss://relay2.example.com"
    ]
  }
}

Se a pubkey corresponder àquela fornecida em "names" (como no exemplo acima), isso significa que a associação está correta e o identificador "nip05" é válido e pode ser exibido.

O atributo recomendado "relays" pode conter um objeto com chaves públicas como propriedades e listas de URLs de relays como valores. Quando presente, ele pode ser usado para ajudar os clientes a descobrir em quais relays um usuário específico pode ser encontrado. Servidores web que fornecem /.well-known/nostr.json dinamicamente com base na query string DEVEM, quando possível, incluir também os dados de relays para qualquer nome servido na mesma resposta.

§Encontrando usuários a partir do identificador NIP-05

Um cliente pode implementar suporte para encontrar chaves públicas de usuários a partir de identificadores de internet. O fluxo é o mesmo descrito acima, mas de forma inversa: primeiro o cliente busca a URL well-known e, a partir dela, obtém a chave pública do usuário; depois, tenta buscar o evento do tipo 0 desse usuário e verifica se ele possui um "nip05" correspondente.

§Notas

§Identificação, não verificação

O NIP-05 não tem como objetivo verificar um usuário, mas apenas identificá-lo, com a finalidade de facilitar a troca de contatos ou a busca por perfis. Exceções são pessoas que possuem (por exemplo, uma empresa) ou estão associadas (por exemplo, um projeto) a um domínio conhecido, que podem explorar o NIP-05 como uma atestação dessa relação e, assim, obter um elemento adicional de confiança.

§Sugestão de implementação para descoberta de usuários

Um cliente pode usar isso para permitir que usuários busquem outros perfis. Se um cliente tiver uma caixa de busca, por exemplo, um usuário pode digitar bob@example.com, e o cliente reconheceria isso e faria as consultas adequadas para obter a pubkey, sugerindo-a ao usuário.

§Clientes devem sempre seguir chaves públicas, não endereços NIP-05

Por exemplo, se após descobrir que bob@bob.com possui a chave pública abc...def, e o usuário clicar para seguir esse perfil, o cliente deve manter como referência primária abc...def, e não bob@bob.com. Se, por qualquer motivo, o endereço:

https://bob.com/.well-known/nostr.json?name=bob

passar a retornar a chave pública 1d2...e3f no futuro, o cliente não deve substituir abc...def na lista de perfis seguidos (mas deve parar de exibir bob@bob.com, já que esse "nip05" se tornou inválido).

§Chaves públicas devem estar em formato hexadecimal

As chaves devem ser retornadas em formato hexadecimal. Chaves no formato NIP-19 (npub) destinam-se apenas à exibição em interfaces de usuário, não a este NIP.

§Exibindo apenas o domínio como identificador

Clientes podem tratar o identificador _@domain como o identificador “raiz” e optar por exibi-lo apenas como <domain>. Por exemplo, se Bob possui bob.com, ele pode não querer um identificador como bob@bob.com, por ser redundante. Em vez disso, Bob pode usar _@bob.com e esperar que os clientes Nostr exibam isso simplesmente como bob.com.

§Justificativa para o formato /.well-known/nostr.json?name=<local-part>

Ao adicionar o <local-part> como query string em vez de parte do caminho, o protocolo pode suportar tanto servidores dinâmicos, que geram JSON sob demanda, quanto servidores estáticos, com um único arquivo JSON contendo vários nomes.

§Permitindo acesso a partir de aplicações JavaScript

Aplicações Nostr em JavaScript podem ser limitadas por políticas de CORS do navegador, que impedem o acesso a /.well-known/nostr.json no domínio do usuário. Quando o CORS impede o carregamento de um recurso, o aplicativo JS vê isso como uma falha de rede, idêntica à inexistência do recurso, não sendo possível determinar com certeza que a falha foi causada por CORS.

Aplicações Nostr em JS que encontrarem falhas ao requisitar /.well-known/nostr.json podem recomendar que os usuários verifiquem a política de CORS de seus servidores, por exemplo:

$ curl -sI https://example.com/.well-known/nostr.json?name=bob | grep -i ^Access-Control
Access-Control-Allow-Origin: *

Os usuários devem garantir que seu /.well-known/nostr.json seja servido com o cabeçalho HTTP:

Access-Control-Allow-Origin: *

para que possa ser validado por aplicações JavaScript puras executadas em navegadores modernos.

§Restrições de segurança

O endpoint /.well-known/nostr.json NÃO DEVE retornar redirecionamentos HTTP.

Os clientes que realizam a busca DEVEM ignorar quaisquer redirecionamentos HTTP retornados por esse endpoint.