Ao fazer uma requisição ao relay ele me retorna apenas um evento como resposta, quando eu gostaria de receber alguns ou todos os eventos de um determinado usuário.
Alguém aí estudando o protocolo nostr que pode me ajudar?
Discussion
Que estranho. 🤔
O padrão é retornar tudo, a menos que você coloque algum filtro.
Para conseguir os eventos de algum determinado npub você deve abrir uma conexão websocket com o relay.
E enviar a requisição.
No formato
["REQ",
Você deve deixar essa String "REQ" como está, escolher um subscription_id pode ser qualquer coisa contanto que seja único, e colocar quais são os filtros. 🤔
Os filtros deve ser json.
Aqui está um exemplo de como consigo todos os eventos do seu npub:
me conecto com um relay que você usa, por exemplo wss://relay.damus.io e envio uma requisição:
["REQ","abc", {"kinds":[1], "authors": ["912aa339f3f0c6401da45ec920e7f4f751c56990c8b4e85c912c4161272ad28d"]}]
abc é meu subscription_id que vou usar até fechar a conexão e o kinds 1 e authors com esses caracteres estranho aí são meus filtros.
Kinds está entre colchetes pois deve ser uma lista, no meu caso só estou interessado no kind 1, e mesma coisa para os authors.
Esses caracteres estranho em authors é o hex do seu npub que eu consegui com uma biblioteca nostr qualquer que decodifica npubs. 😴
Uma possível explicação para isso é voce estar utilizando "limit": 1 🤔
Isso, estou fazendo deste jeito, mas por algum motivo ainda não saiu do jeito que espero.
Outro ponto que me deixar encabulado e essa subscription=arbitrary_string, isso não deveria ser o número informado pelo relay?
Não. Você escolhe, é temporário, só para te indentificar enquanto a conexão estiver aberta.
Pro relay saber para quem enviar os dados.
Está correto, é assi mesmo!
Quando você envia a mensagem para o relay solititando os eventos, você 'seta' um listener "message" que receberá os eventos, porém, recebe evento a evento, e no final vocẽ recebe um "EOSE", que indica o fim da resposta do relay.
Então, vocẽ provavelmente está enviando o "REQ" e setando o listener "message", porém, fechando assim que recebe o primeiro evento, então receberá sempre o primeiro evento e fechar o listener. Você deve enviar o "REQ" e deixar o listener esperando por um tempo limite "timeout", tenho um código de exemplo:
Em typescript fica assim utilizando Promise:
Provavelmente deve ser isso.
Lendo a documentação da lib websocket lá informar que estás questões de comunicação não deveria ser precaução do dev, a lib cuida disso por debaixo dos panos.
Que mesmo que a mensagem seja fragmentada a lib pegar todas as partes monta e retorna o resultado. Por isso não me preocupei com essa parte da comunicação.
Vou fazer os testes essa parte do listener
Se não quiser mexer diretamente com websocket tem a lib nostr-tools que é uma mão na roda.
Dá um npm install nostr-tools e npm install ws
E aqui está o código:
Antes só faça uma coisinha, vá em node_modules/nostr-tools/lib/esm/relay.js e coloque import WebSocket from 'ws'
O código:
import { Relay } from 'nostr-tools/relay'
const relay = await Relay.connect('wss://relay.damus.io')
console.log(`connected to ${relay.url}`)
// let's query for an event that exists
const sub = relay.subscribe([
{
"kinds": [1],
"authors": ['912aa339f3f0c6401da45ec920e7f4f751c56990c8b4e85c912c4161272ad28d'],
},
], {
onevent(event) {
console.log('we got the event we wanted:', event.content)
},
oneose() {
sub.close()
}
})
Deu certo era isso mesmo nostr:nprofile1qqs923ewnsqlx7347cpjhxmcmt0rsmnwf3tasr736pjx4wee9q89ufcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9thwden5te0dehhxarj9ehhsarj9ejx2a30qy88wumn8ghj7mn0wvhxcmmv9uh7lm3t resolvido com uma abordagem assíncrona para manter a conexão aberta.
Isso ai grande homem!!!
Imaginei que seria isso mesmo, intuitivamente a gente acha que uma execução só, irá retornar todos os eventos etc..
Ai sim Man, mais um passo pra dominar o protocolo!!
Você recebe apenas um evento por vez no seu listener, se o relay for enviar 100 eventos, ele irá enviar 101 mensagens, sendo 100 com eventos e uma última com um "EOSE" de sinalização do final.