5967820 on Nostr: #tuxdobananil #explains #nips #nip-11 # NIP-11: Documento de Informação do Relay ...

#tuxdobananil #explains #nips #nip-11

# NIP-11: Documento de Informação do Relay 🛰️

## Visão Geral

NIP-11 introduz um padrão para que relays forneçam metadados via HTTP, detalhando suas capacidades, contatos administrativos e atributos diversos. Isso permite que clientes entendam melhor os serviços oferecidos por um relay e como interagir com eles.

### Estrutura do Documento

Quando um relay recebe uma requisição HTTP(s) com o cabeçalho `Accept` de `application/nostr+json`, ele deve retornar um documento JSON com a seguinte estrutura:

```json
{
"name": "string identificando o relay",
"description": "string com informações detalhadas",
"pubkey": "chave pública de contato administrativo",
"contact": "contato alternativo administrativo",
"supported_nips": "lista de números NIP suportados pelo relay",
"software": "URL identificando o software do relay",
"version": "identificador de versão em string"
}
```

Campos podem ser omitidos, e clientes devem ignorar campos adicionais desconhecidos. Relays devem aceitar requisições CORS, enviando os cabeçalhos `Access-Control-Allow-Origin`, `Access-Control-Allow-Headers` e `Access-Control-Allow-Methods`.

### Descrições de Campo

- **Name**: Um nome para uso em softwares clientes. Deve ser uma string com menos de 30 caracteres.
- **Description**: Informações detalhadas em texto puro sobre o relay. Recomenda-se não incluir marcação ou quebras de linha.
- **Pubkey**: Contato administrativo listado como uma chave pública no formato de eventos Nostr (hex de 32 bytes para uma chave pública `secp256k1`).
- **Contact**: Contato alternativo, preferencialmente uma chave pública Nostr. Deve ser um URI usando esquemas como `mailto` ou `https`.
- **Supported NIPs**: Array de identificadores inteiros das NIPs implementadas pelo relay.
- **Software**: URL para a homepage do software do relay.
- **Version**: Versão do software do relay como uma string.

### Limitações do Servidor

Relays podem impor limitações práticas aos clientes, como tamanho máximo de mensagem, número máximo de subscrições, filtros, etc. Essas limitações ajudam a gerenciar a carga no relay e garantir um serviço estável.

### Retenção de Eventos

Relays podem especificar políticas de retenção de eventos para gerenciar o armazenamento. Isso pode incluir limitações baseadas no tipo de evento ou no tempo de retenção.

### Preferências da Comunidade

Relays que visam fomentar uma comunidade local podem especificar tags de idioma, tags de conteúdo limitadas e políticas de postagem para incentivar discussões alinhadas com os valores da comunidade.

### Pagamento para Relay

Relays que exigem pagamentos para certas ações podem expor suas tabelas de taxas, fornecendo URLs para processamento de pagamentos e detalhes sobre as taxas de admissão, subscrição e publicação.

### Ícone

Um URL apontando para uma imagem a ser usada como ícone para o relay, recomendado ser quadrado em forma.

### Exemplos

Um exemplo de comando que fornece resultados para o relay `eden.nostr.land` mostra detalhes como descrição, nome, chave pública, software, NIPs suportadas, limitações e informações sobre pagamentos.

## Conclusão

NIP-11 estabelece um protocolo para que relays compartilhem informações essenciais com clientes, promovendo transparência e ajudando usuários a escolherem relays que melhor atendam às suas necessidades.