Nostr

Um evento contém pubkey, created_at, kind, tags, content, id e sig. NIP-01 deriva id por SHA-256 de uma serialização precisa e usa BIP340 em secp256k1. O cliente verifica integridade e autorização pela chave. O autor fornece created_at; não é um carimbo temporal independente nem prova da verdade do conteúdo. [Nostr — NIP-01: Basic protocol] [fiatjaf — Original Nostr description]

O cliente publica EVENT e subscreve com REQ por WebSocket. OK comunica aceitação ou rejeição por esse relay. EOSE termina a lista de eventos guardados, não necessariamente a subscrição de novos eventos. Nenhuma mensagem confirma entrega ao destinatário, replicação em toda a rede ou armazenamento permanente. [Nostr — NIP-01: Basic protocol]

Num filtro, o evento tem de cumprir todas as condições: autor e tipo significam AND. Vários filtros num REQ combinam-se com OR; basta um. limit restringe a lista inicial, não o número de eventos futuros. Um resultado ausente pode indicar histórico limitado do relay, não inexistência do evento. [Nostr — NIP-01: Basic protocol]

Eventos substituíveis comparam-se por pubkey e kind; os endereçáveis também pela etiqueta d. Uma versão nova pode substituir a anterior; com tempos iguais, prevalece o id lexicograficamente menor. Não se espera guardar eventos efémeros. As regras descrevem o relay, não um arquivo global imutável; as implementações podem diferir. [Nostr — NIP-01: Basic protocol]

NIP-19 usa Bech32 para apresentação: npub indica a chave pública, nsec a privada. Codificação não é encriptação. Partilhar nsec entrega a chave secreta, não apenas uma ligação de perfil. Eventos e filtros NIP-01 usam chaves públicas hexadecimais, não a apresentação npub. [Nostr — NIP-19: Encoded entities]

NIP-05 associa um nome semelhante a e-mail a uma chave pública segundo a resposta do domínio. Prova essa associação, não a identidade real nem a honestidade. O cliente deve seguir a chave original: se o domínio associar o nome a outra chave, não deve substituir automaticamente o perfil seguido pela nova chave. [Nostr — NIP-05: Internet identifiers]

NIP-09 define o pedido do autor para remover os seus eventos. Antes de os ocultar, o cliente deve verificar que original e pedido têm a mesma chave pública. Relays e clientes podem processá-lo, mas o protocolo não remove todas as cópias descarregadas ou guardadas. Apagar numa interface não prova eliminação global. [Nostr — NIP-09: Deletion requests]

NIP-44 define um payload encriptado, não um sistema completo de mensagens privadas; NIP-17 acrescenta invólucros e regras de entrega. NIP-44 sozinho não fornece forward secrecy após um comprometimento posterior da chave. Endereços de rede, horários e comportamento do cliente continuam relevantes. O suporte dos NIP deve ser distinguido por aplicação. [Nostr — NIP-44: Encrypted payloads] [Nostr — NIP-17: Private messages]