Song Jong on Nostr: #tuxdobananil #explains #nips #nip-42 ### NIP-42: Autenticação de Clientes para ...
#tuxdobananil #explains #nips #nip-42
### NIP-42: Autenticação de Clientes para Relays 🛡️🔑
**O que é NIP-42?** 🤔
- Uma proposta que define um método para clientes se autenticarem em relays por meio da assinatura de um evento efêmero.
**Motivação:** 🌟
- Relays podem querer exigir autenticação para acesso a recursos restritos, como:
- Solicitar pagamento ou outra forma de whitelist para publicar eventos.
- Limitar acesso a mensagens diretas (`kind: 4`) apenas às partes envolvidas na troca de chat.
- Limitar subscrições a usuários pagantes ou whitelistados, exigindo autenticação.
### Novas Mensagens no Protocolo Cliente-Relay: 📬
- **`AUTH`**: Mensagem que relays podem enviar quando suportam autenticação e que clientes podem enviar aos relays para se autenticarem.
- Quando enviada por relays: `["AUTH", <challenge-string>]`
- Quando enviada por clientes: `["AUTH", <signed-event-json>]`
### Evento de Autenticação Canônico: 📜
- Um evento efêmero de `kind: 22242`, não destinado à publicação ou consulta, com tags para a URL do relay e a string de desafio recebida do relay. Exemplo:
```json
{
"kind": 22242,
"tags": [
["relay", "wss://relay.example.com/"],
["challenge", "challengestringhere"]
],
...
}
```
### Prefixos `OK` e `CLOSED` Machine-Readable: 🤖
- `"auth-required: "`: Quando um cliente não realizou `AUTH` e o relay exige isso para completar a consulta ou escrever o evento.
- `"restricted: "`: Quando um cliente já realizou `AUTH`, mas a chave usada não é permitida pelo relay ou excede sua autorização.
### Fluxo do Protocolo: 🔄
- Relays podem enviar uma mensagem `AUTH` contendo um desafio a qualquer momento. O desafio é válido pela duração da conexão ou até que outro desafio seja enviado pelo relay. O cliente pode decidir enviar seu evento `AUTH` em qualquer ponto, e a sessão autenticada é válida depois disso pela duração da conexão.
#### `auth-required` em resposta a uma mensagem `REQ`: 💬
- Um relay pode exigir autenticação para certas tarefas, como responder a uma `REQ` ou aceitar uma escrita de `EVENT`. O cliente deve armazenar um desafio associado a esse relay para agir em resposta à mensagem `CLOSED` com `auth-required`.
### Verificação de Evento Assinado: 🔍
Para verificar mensagens `AUTH`, relays devem garantir:
- Que o `kind` seja `22242`.
- Que o evento `created_at` esteja próximo do tempo atual (ex: dentro de ~10 minutos).
- Que a tag `"challenge"` corresponda ao desafio enviado anteriormente.
- Que a tag `"relay"` corresponda à URL do relay.
**Conclusão:** 💡
NIP-42 apresenta uma solução robusta para autenticação de clientes em relays, permitindo acesso controlado a recursos restritos e melhorando a segurança e a gestão de acessos dentro do ecossistema Nostr.
### NIP-42: Autenticação de Clientes para Relays 🛡️🔑
**O que é NIP-42?** 🤔
- Uma proposta que define um método para clientes se autenticarem em relays por meio da assinatura de um evento efêmero.
**Motivação:** 🌟
- Relays podem querer exigir autenticação para acesso a recursos restritos, como:
- Solicitar pagamento ou outra forma de whitelist para publicar eventos.
- Limitar acesso a mensagens diretas (`kind: 4`) apenas às partes envolvidas na troca de chat.
- Limitar subscrições a usuários pagantes ou whitelistados, exigindo autenticação.
### Novas Mensagens no Protocolo Cliente-Relay: 📬
- **`AUTH`**: Mensagem que relays podem enviar quando suportam autenticação e que clientes podem enviar aos relays para se autenticarem.
- Quando enviada por relays: `["AUTH", <challenge-string>]`
- Quando enviada por clientes: `["AUTH", <signed-event-json>]`
### Evento de Autenticação Canônico: 📜
- Um evento efêmero de `kind: 22242`, não destinado à publicação ou consulta, com tags para a URL do relay e a string de desafio recebida do relay. Exemplo:
```json
{
"kind": 22242,
"tags": [
["relay", "wss://relay.example.com/"],
["challenge", "challengestringhere"]
],
...
}
```
### Prefixos `OK` e `CLOSED` Machine-Readable: 🤖
- `"auth-required: "`: Quando um cliente não realizou `AUTH` e o relay exige isso para completar a consulta ou escrever o evento.
- `"restricted: "`: Quando um cliente já realizou `AUTH`, mas a chave usada não é permitida pelo relay ou excede sua autorização.
### Fluxo do Protocolo: 🔄
- Relays podem enviar uma mensagem `AUTH` contendo um desafio a qualquer momento. O desafio é válido pela duração da conexão ou até que outro desafio seja enviado pelo relay. O cliente pode decidir enviar seu evento `AUTH` em qualquer ponto, e a sessão autenticada é válida depois disso pela duração da conexão.
#### `auth-required` em resposta a uma mensagem `REQ`: 💬
- Um relay pode exigir autenticação para certas tarefas, como responder a uma `REQ` ou aceitar uma escrita de `EVENT`. O cliente deve armazenar um desafio associado a esse relay para agir em resposta à mensagem `CLOSED` com `auth-required`.
### Verificação de Evento Assinado: 🔍
Para verificar mensagens `AUTH`, relays devem garantir:
- Que o `kind` seja `22242`.
- Que o evento `created_at` esteja próximo do tempo atual (ex: dentro de ~10 minutos).
- Que a tag `"challenge"` corresponda ao desafio enviado anteriormente.
- Que a tag `"relay"` corresponda à URL do relay.
**Conclusão:** 💡
NIP-42 apresenta uma solução robusta para autenticação de clientes em relays, permitindo acesso controlado a recursos restritos e melhorando a segurança e a gestão de acessos dentro do ecossistema Nostr.