Song Jong on Nostr: #tuxdobananil #explains #nips #nip-65 # NIP-65: Metadados de Lista de Relays 📡📝 ...
#tuxdobananil #explains #nips #nip-65
# NIP-65: Metadados de Lista de Relays 📡📝
## Resumo:
NIP-65 introduz um evento substituível (`kind:10002`) para anunciar relays preferenciais para a descoberta do conteúdo de um usuário e para receber conteúdo atualizado de outros.
### Estrutura do Evento:
- **Inclui**: Lista de tags `r` com URIs de relay e marcadores `read` ou `write`.
- **Relays `read`**: Usados para ler eventos **sobre** um usuário.
- **Relays `write`**: Usados para escrever eventos **de** um usuário.
- Sem marcador: Assume-se que o relay serve para ambos propósitos.
### Uso:
- `.content`: Não utilizado.
- **Leitura e Escrita**:
- Para eventos **de** um usuário: Use relays `write`.
- Para eventos **sobre** um usuário: Use relays `read`.
### Motivação:
- Reduz a centralização em grandes operadores de relay, permitindo conexão direta com conjuntos de relays atualizados de cada usuário.
- Diminui a necessidade de postar em relays populares para obter visibilidade.
### Considerações Finais:
1. **Tamanho da Lista**: Recomenda-se manter pequena (2-4 relays).
2. **Difusão do Evento**: Espalhar o evento `kind:10002` do autor pelo maior número possível de relays.
3. **Uso Primário**: Anunciar os relays preferenciais do usuário; o cliente do usuário pode usar outras heurísticas para selecionar relays para busca de dados.
4. **DMs**: Transmitir apenas aos relays `write` do autor e `read` do destinatário para máxima privacidade.
5. **Suporte de Relays**: Se um relay indica suporte a este NIP em seu documento [NIP-11](11.md), ele está disposto a aceitar eventos `kind:10002` de uma ampla gama de usuários.
6. **Deduplicação**: Os clientes devem deduplicar conexões normalizando URIs de relay de acordo com o [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6).
Esse protocolo visa melhorar a eficiência e privacidade na distribuição e recebimento de conteúdo dentro da rede NOSTR, descentralizando a infraestrutura de relays.
# NIP-65: Metadados de Lista de Relays 📡📝
## Resumo:
NIP-65 introduz um evento substituível (`kind:10002`) para anunciar relays preferenciais para a descoberta do conteúdo de um usuário e para receber conteúdo atualizado de outros.
### Estrutura do Evento:
- **Inclui**: Lista de tags `r` com URIs de relay e marcadores `read` ou `write`.
- **Relays `read`**: Usados para ler eventos **sobre** um usuário.
- **Relays `write`**: Usados para escrever eventos **de** um usuário.
- Sem marcador: Assume-se que o relay serve para ambos propósitos.
### Uso:
- `.content`: Não utilizado.
- **Leitura e Escrita**:
- Para eventos **de** um usuário: Use relays `write`.
- Para eventos **sobre** um usuário: Use relays `read`.
### Motivação:
- Reduz a centralização em grandes operadores de relay, permitindo conexão direta com conjuntos de relays atualizados de cada usuário.
- Diminui a necessidade de postar em relays populares para obter visibilidade.
### Considerações Finais:
1. **Tamanho da Lista**: Recomenda-se manter pequena (2-4 relays).
2. **Difusão do Evento**: Espalhar o evento `kind:10002` do autor pelo maior número possível de relays.
3. **Uso Primário**: Anunciar os relays preferenciais do usuário; o cliente do usuário pode usar outras heurísticas para selecionar relays para busca de dados.
4. **DMs**: Transmitir apenas aos relays `write` do autor e `read` do destinatário para máxima privacidade.
5. **Suporte de Relays**: Se um relay indica suporte a este NIP em seu documento [NIP-11](11.md), ele está disposto a aceitar eventos `kind:10002` de uma ampla gama de usuários.
6. **Deduplicação**: Os clientes devem deduplicar conexões normalizando URIs de relay de acordo com o [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6).
Esse protocolo visa melhorar a eficiência e privacidade na distribuição e recebimento de conteúdo dentro da rede NOSTR, descentralizando a infraestrutura de relays.