[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6},"actionData","errors","routes/hashtag",{"_7":8,"_9":10,"_11":12},"articles",[13,14,15],"authors",{},"tag","relays nostr",{"_16":131,"_18":132,"_20":133,"_22":23,"_24":25,"_26":134,"_28":135},{"_16":87,"_18":88,"_20":89,"_22":23,"_24":25,"_26":90,"_28":91},{"_16":17,"_18":19,"_20":21,"_22":23,"_24":25,"_26":27,"_28":29},"content","## Mensagem Direta Criptografada\n\n`final` `unrecommended` `optional`\n\nUm evento especial com o *kind* `4`, que significa **“mensagem direta criptografada”**. Ele deve possuir os seguintes atributos:\n\n## **`content`**\n\n**DEVE** ser igual a uma string criptografada com **AES-256-CBC**, codificada em **base64**, contendo qualquer texto que o usuário queira escrever.\n\nEssa criptografia deve ser feita usando um **cifra compartilhada**, gerada pela combinação da **chave pública do destinatário** com a **chave privada do remetente**.\n\nO conteúdo criptografado deve ser **concatenado** com o **vetor de inicialização (IV)**, também codificado em base64, como se fosse um parâmetro de query string chamado `\"iv\"`.\n\nO formato deve ser o seguinte:\n\n```\n\"content\": \"?iv=\"\n```\n\n## **`tags`**\n\n**DEVE** conter uma entrada identificando o **destinatário da mensagem** (para que os relays possam encaminhar naturalmente esse evento a ele), no formato:\n\n```\n[\"p\", \"\"]\n```\n\n## **`tags` (opcional)**\n\n**PODE** conter uma entrada identificando a **mensagem anterior de uma conversa** ou uma mensagem específica à qual estamos respondendo (permitindo conversas mais organizadas e contextuais), no formato:\n\n```\n[\"e\", \"\"]\n```\n\n## **Nota**\n\nPor padrão, na implementação ECDH da biblioteca [libsecp256k1](https://github.com/bitcoin-core/secp256k1), o segredo é o **hash SHA256 do ponto compartilhado** (incluindo as coordenadas X e Y).\n\nNo Nostr, **apenas a coordenada X do ponto compartilhado é usada como segredo**, e **ela NÃO é hasheada**.\n\nAo usar a libsecp256k1, uma função personalizada que copie apenas a coordenada X deve ser passada como argumento `hashfp` na função `secp256k1_ecdh`. Veja [aqui](https://github.com/bitcoin-core/secp256k1/blob/master/src/modules/ecdh/main_impl.h#L29).\n\n## Exemplo de código em JavaScript para gerar esse evento:\n\n```js\nimport crypto from 'crypto'\nimport * as secp from '@noble/secp256k1'\n\nlet sharedPoint = secp.getSharedSecret(ourPrivateKey, '02' + theirPublicKey)\nlet sharedX = sharedPoint.slice(1, 33)\n\nlet iv = crypto.randomFillSync(new Uint8Array(16))\nvar cipher = crypto.createCipheriv(\n 'aes-256-cbc',\n Buffer.from(sharedX),\n iv\n)\nlet encryptedMessage = cipher.update(text, 'utf8', 'base64')\nencryptedMessage += cipher.final('base64')\nlet ivBase64 = Buffer.from(iv.buffer).toString('base64')\n\nlet event = {\n pubkey: ourPubKey,\n created_at: Math.floor(Date.now() / 1000),\n kind: 4,\n tags: [['p', theirPublicKey]],\n content: encryptedMessage + '?iv=' + ivBase64\n}\n```\n\n## ⚠️ Aviso de Segurança\n\nEste padrão **não chega nem perto** do que é considerado o estado da arte em comunicação criptografada entre pares e **vaza metadados nos eventos**.\n\nPortanto, **não deve ser usado para nada que realmente precise ser mantido em segredo**, e somente com relays que utilizem `AUTH` para restringir quem pode buscar seus eventos de `kind:4`.\n\n## ⚠️ Aviso para Implementação em Clientes\n\nClientes **não devem** procurar e substituir referências a chaves públicas ou notas dentro do `.content`.\n\nSe o conteúdo for processado como uma nota de texto comum (onde `@npub...` é substituído por `#[0]` com uma tag `[\"p\", \"...\"]`), essas tags serão vazadas e o usuário mencionado receberá a mensagem na caixa de entrada.\n","created_at",1769120831,"id","3c84cb920290b0c6387ffef82e5a5b8d88af6ebea722e3be420a2064236e0864","kind",30023,"pubkey","2a356b8ae4c9f4107d1dce3b6e7a43736e413ef4f73d439198c7ae8de4588e82","sig","d9a6ccc6239f3fe1f1c197f0fb4a4c17274e28c0f16c0d344b5661e73c1a77e9372f298c9a7f28c0c4f2a3e0fcc545c03986de5aa16bcad60909c6747c8fb690","tags",[30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55],[85,86],[83,84],[81,82],[79,80],[77,78],[56,76],[56,75],[56,74],[56,73],[56,72],[56,71],[56,70],[56,69],[56,68],[56,67],[56,66],[56,65],[56,64],[56,63],[56,62],[56,61],[56,12],[56,60],[56,59],[56,58],[56,57],"t","nip-4","social network protocol","rede social","descentralizados","nostr clients","criptografia","ti","tecnologia","programacao","nostr explained","nostr português","nostr brasil","nostr introduction","como funciona o nostr","nostr tutorial","nostr para iniciantes","o que é nostr","protocolo nostr","nostr","nip-04","published_at","1769120831","image","https://image.nostr.build/26b878ccb338264f428ad04c26b969676d15da1d4c4aa95c82a80266e7036e0c.png","summary","O nip 4 define o funcionamento das mensagens diretas criptografadas (kind 4).","title","NIP-04","d","nip04","**Mapeamento de chaves Nostr para identificadores de internet baseados em DNS**\n\n`final` `optional`\n\nEm eventos do tipo `0` (*user metadata*), é possível especificar a chave `\"nip05\"` com um [identificador de internet](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (um endereço no formato de e-mail) como valor.\nEmbora exista um link acima para uma especificação muito liberal de “identificador de internet”, o NIP-05 assume que a parte `` será restrita aos caracteres `a-z0-9-_.`, sem diferenciar maiúsculas de minúsculas.\n\nAo encontrar isso, o cliente divide o identificador em `` e `` e usa esses valores para fazer uma requisição GET para:\n\n```\nhttps:///.well-known/nostr.json?name=\n```\n\nO resultado deve ser um documento JSON contendo uma chave `\"names\"`, que deve ser um mapeamento de nomes para chaves públicas em formato hexadecimal.\nSe a chave pública associada ao `` corresponder à `pubkey` do evento de *user metadata*, então o cliente conclui que aquela chave pública pode de fato ser referenciada por esse identificador.\n\n---\n\n## Exemplo\n\nSe um cliente encontrar um evento como este:\n\n```jsonc\n{\n \"pubkey\": \"b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9\",\n \"kind\": 0,\n \"content\": \"{\\\"name\\\": \\\"bob\\\", \\\"nip05\\\": \\\"bob@example.com\\\"}\"\n // outros campos...\n}\n```\n\nEle fará uma requisição GET para:\n\n```\nhttps://example.com/.well-known/nostr.json?name=bob\n```\n\nE receberá uma resposta como:\n\n```json\n{\n \"names\": {\n \"bob\": \"b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9\"\n }\n}\n```\n\nOu com o atributo **recomendado** `\"relays\"`:\n\n```json\n{\n \"names\": {\n \"bob\": \"b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9\"\n },\n \"relays\": {\n \"b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9\": [\n \"wss://relay.example.com\",\n \"wss://relay2.example.com\"\n ]\n }\n}\n```\n\nSe a `pubkey` corresponder àquela fornecida em `\"names\"` (como no exemplo acima), isso significa que a associação está correta e o identificador `\"nip05\"` é válido e pode ser exibido.\n\nO atributo recomendado `\"relays\"` pode conter um objeto com chaves públicas como propriedades e listas de URLs de relays como valores. Quando presente, ele pode ser usado para ajudar os clientes a descobrir em quais relays um usuário específico pode ser encontrado.\nServidores web que fornecem `/.well-known/nostr.json` dinamicamente com base na *query string* **DEVEM**, quando possível, incluir também os dados de relays para qualquer nome servido na mesma resposta.\n\n---\n\n## Encontrando usuários a partir do identificador NIP-05\n\nUm cliente pode implementar suporte para encontrar chaves públicas de usuários a partir de *identificadores de internet*. O fluxo é o mesmo descrito acima, mas de forma inversa: primeiro o cliente busca a URL *well-known* e, a partir dela, obtém a chave pública do usuário; depois, tenta buscar o evento do tipo `0` desse usuário e verifica se ele possui um `\"nip05\"` correspondente.\n\n---\n\n## Notas\n\n## Identificação, não verificação\n\nO NIP-05 **não** tem como objetivo verificar um usuário, mas apenas identificá-lo, com a finalidade de facilitar a troca de contatos ou a busca por perfis.\nExceções são pessoas que possuem (por exemplo, uma empresa) ou estão associadas (por exemplo, um projeto) a um domínio conhecido, que podem explorar o NIP-05 como uma atestação dessa relação e, assim, obter um elemento adicional de confiança.\n\n---\n\n## Sugestão de implementação para descoberta de usuários\n\nUm cliente pode usar isso para permitir que usuários busquem outros perfis. Se um cliente tiver uma caixa de busca, por exemplo, um usuário pode digitar `bob@example.com`, e o cliente reconheceria isso e faria as consultas adequadas para obter a `pubkey`, sugerindo-a ao usuário.\n\n---\n\n## Clientes devem sempre seguir chaves públicas, não endereços NIP-05\n\nPor exemplo, se após descobrir que `bob@bob.com` possui a chave pública `abc...def`, e o usuário clicar para seguir esse perfil, o cliente deve manter como referência primária `abc...def`, e não `bob@bob.com`.\nSe, por qualquer motivo, o endereço:\n\n```\nhttps://bob.com/.well-known/nostr.json?name=bob\n```\n\npassar a retornar a chave pública `1d2...e3f` no futuro, o cliente **não deve** substituir `abc...def` na lista de perfis seguidos (mas deve parar de exibir `bob@bob.com`, já que esse `\"nip05\"` se tornou inválido).\n\n---\n\n## Chaves públicas devem estar em formato hexadecimal\n\nAs chaves devem ser retornadas em formato hexadecimal.\nChaves no formato NIP-19 (`npub`) destinam-se apenas à exibição em interfaces de usuário, não a este NIP.\n\n---\n\n## Exibindo apenas o domínio como identificador\n\nClientes podem tratar o identificador `_@domain` como o identificador “raiz” e optar por exibi-lo apenas como ``.\nPor exemplo, se Bob possui `bob.com`, ele pode não querer um identificador como `bob@bob.com`, por ser redundante. Em vez disso, Bob pode usar `_@bob.com` e esperar que os clientes Nostr exibam isso simplesmente como `bob.com`.\n\n---\n\n## Justificativa para o formato `/.well-known/nostr.json?name=`\n\nAo adicionar o `` como *query string* em vez de parte do caminho, o protocolo pode suportar tanto servidores dinâmicos, que geram JSON sob demanda, quanto servidores estáticos, com um único arquivo JSON contendo vários nomes.\n\n---\n\n## Permitindo acesso a partir de aplicações JavaScript\n\nAplicações Nostr em JavaScript podem ser limitadas por políticas de [CORS][] do navegador, que impedem o acesso a `/.well-known/nostr.json` no domínio do usuário.\nQuando o CORS impede o carregamento de um recurso, o aplicativo JS vê isso como uma falha de rede, idêntica à inexistência do recurso, não sendo possível determinar com certeza que a falha foi causada por CORS.\n\nAplicações Nostr em JS que encontrarem falhas ao requisitar `/.well-known/nostr.json` podem recomendar que os usuários verifiquem a política de CORS de seus servidores, por exemplo:\n\n```bash\n$ curl -sI https://example.com/.well-known/nostr.json?name=bob | grep -i ^Access-Control\nAccess-Control-Allow-Origin: *\n```\n\nOs usuários devem garantir que seu `/.well-known/nostr.json` seja servido com o cabeçalho HTTP:\n\n```\nAccess-Control-Allow-Origin: *\n```\n\npara que possa ser validado por aplicações JavaScript puras executadas em navegadores modernos.\n\n[CORS]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS\n\n---\n\n## Restrições de segurança\n\nO endpoint `/.well-known/nostr.json` **NÃO DEVE** retornar redirecionamentos HTTP.\n\nOs clientes que realizam a busca **DEVEM ignorar** quaisquer redirecionamentos HTTP retornados por esse endpoint.\n",1769121169,"3fc005ef504963cc498f72530c48afb8cbb3dc3a66eb8e96cc959d6ce191eb81","eb93457f7a538cdb9e70e8cc4416698a8a6e88f894db704c98c0b7f09da11a3d30c3ab58cb1aff531189bf06c5739ed61deaddbaada9b7888ecd7ae2fc93056b",[92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118],[85,130],[83,129],[81,128],[79,127],[77,126],[56,125],[56,64],[56,75],[56,124],[56,73],[56,72],[56,71],[56,70],[56,69],[56,68],[56,67],[56,66],[56,123],[56,61],[56,12],[56,122],[56,60],[56,59],[56,121],[56,58],[56,120],[56,119],"nip-5","open protocols","descentralizada","protocolos","nips","protocolo-nostr","nip-05","1769121169","https://image.nostr.build/5be4413a359f4234b84f411756c91b10a0dfe4c434253f5f44b01990b701f41d.png","O NIP-05 permite associar chaves públicas a identificadores amigáveis no formato de e-mail (como nome@dominio.com).","NIP-05","nip05","**Capacidade `window.nostr` para navegadores web**\n\n`draft` `optional`\n\nO objeto `window.nostr` pode ser disponibilizado por navegadores web ou extensões, e sites ou aplicações web podem fazer uso dele após verificar sua disponibilidade.\n\nEsse objeto deve definir os seguintes métodos:\n\n```ts\nasync window.nostr.getPublicKey(): string\n// retorna uma chave pública em formato hexadecimal\n\nasync window.nostr.signEvent(event: {\n created_at: number,\n kind: number,\n tags: string[][],\n content: string\n}): Event\n// recebe um objeto de evento, adiciona `id`, `pubkey` e `sig` e o retorna\n```\n\nAlém desses dois métodos básicos acima, as seguintes funções também podem ser implementadas de forma opcional:\n\n```ts\nasync window.nostr.nip04.encrypt(pubkey, plaintext): string\n// retorna ciphertext e iv conforme especificado no nip-04 (obsoleto)\n\nasync window.nostr.nip04.decrypt(pubkey, ciphertext): string\n// recebe ciphertext e iv conforme especificado no nip-04 (obsoleto)\n\nasync window.nostr.nip44.encrypt(pubkey, plaintext): string\n// retorna ciphertext conforme especificado no nip-44\n\nasync window.nostr.nip44.decrypt(pubkey, ciphertext): string\n// recebe ciphertext conforme especificado no nip-44\n```\n\n---\n\n### Recomendação para autores de extensões\n\nPara garantir que o `window.nostr` esteja disponível para clientes Nostr no momento do carregamento da página, autores que criam extensões para Chromium e Firefox devem carregar seus scripts especificando:\n\n```json\n\"run_at\": \"document_end\"\n```\n\nno manifesto da extensão.\n\n---\n\n### Implementação\n\nVeja:\n[https://github.com/aljazceru/awesome-nostr#nip-07-browser-extensions](https://github.com/aljazceru/awesome-nostr#nip-07-browser-extensions)\n",1769627472,"5eb1d21acf6c7c287489d50f759471846acf9804a4a3cc21adff88252826dc7b","fb30da6fb8069d4a75b2dbc01f92c957a08bef01e1b033c5f5c3ace7cc49e11632fc8eb2af27ab2c646f9f1fd6f97927bdfe244de9c84acfb0f4db5776cb303c",[136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162],[85,171],[83,170],[81,169],[79,168],[77,167],[56,166],[56,165],[56,75],[56,74],[56,73],[56,72],[56,71],[56,70],[56,69],[56,68],[56,67],[56,66],[56,123],[56,164],[56,61],[56,12],[56,122],[56,60],[56,59],[56,121],[56,163],[56,120],"ial network protocol","nostr relays","nip-7","nip-07","1769627472","https://image.nostr.build/9cf846eb779a8936f166ced1c778e9d4a27b751c094cebebafafc3261ac1a737.png","Especificação do protocolo Nostr voltada para navegação web e aplicações web.","NIP-07","nip07"]