NIP-42 define como clientes se autenticam em relays. Relays podem exigir autenticação para aplicar controle de acesso, prevenir abuso ou implementar serviços de relay pagos.

Como funciona

O fluxo de autenticação começa quando um relay envia uma mensagem AUTH ao cliente. Essa mensagem contém uma challenge string que o cliente precisa assinar. O cliente cria um evento de autenticação kind 22242 contendo a challenge e o assina com sua chave privada. O relay verifica a assinatura e a challenge e então concede acesso.

{
  "kind": 22242,
  "tags": [
    ["relay", "wss://relay.example.com"],
    ["challenge", "random-challenge-string"]
  ],
  "content": "",
  "pubkey": "<client_pubkey>",
  "created_at": 1736784000,
  "sig": "<signature>"
}

A challenge previne ataques de replay. A URL do relay nas tags impede que o mesmo evento assinado seja reutilizado em relays diferentes.

Notas de protocolo

A autenticação tem escopo de conexão. Uma challenge permanece válida pela duração da conexão, ou até que o relay envie uma nova. O evento assinado é efêmero e não deve ser transmitido como um evento normal.

A spec também define prefixos de erro legíveis por máquina. auth-required: significa que o cliente ainda não se autenticou. restricted: significa que ele se autenticou, mas aquela pubkey ainda não tem permissão para a ação solicitada.

Casos de uso

Relays pagos usam NIP-42 para verificar assinantes antes de conceder acesso. Relays privados a usam para limitar leitura ou escrita a pubkeys aprovadas. Ela também melhora rate limiting porque relays conseguem acompanhar comportamento por chave autenticada, e não apenas por endereço IP.

Combinada com metadados da NIP-11, clientes podem descobrir se um relay suporta NIP-42 antes de tentar queries protegidas. Na prática, o suporte ainda é desigual, então clientes precisam de fallback quando um relay anuncia NIP-42 mas lida incorretamente com eventos protegidos.

Fontes primárias:

Mencionado em:

Veja também: