Yonle's avatar
Yonle _@yonle.page.my.id 1 year ago
We all know that connections to #nostr relays are mostly done via websocket. And then i got an idea: How about i create a way to communicate with Nostr relays via HTTP instead? You see, We have QUIC already, And we know that most social media apps were using HTTP to communicate. But we are using websocket. So what's wrong with it? As a mobile data user, I am struggling to solve the high bandwidth problem. So there we go, an prototype nhttp (Nostr over HTTP). It got basic stuff already: REQ, and event publishing
GitHub
GitHub - Yonle/nhttp: Nostr over HTTP communication.
Nostr over HTTP communication. Contribute to Yonle/nhttp development by creating an account on GitHub.

Replies (14)

Yonle's avatar
Yonle _@yonle.page.my.id 1 year ago
So in case if anyone ask, Why in HTTP? Short explanation: We could abort REQ subscription abruptly once unneeded, Because in a slow connection, sending CLOSE to relay will still make your nostr client to receive events for specified sub still. Above of that, There's no perfect time for gzip to compress these fast pacing ["EVENT". You don't need to blame websocket. That's how tcp naturally works. Just like a non-working CTRL + C when doing a long output when doing `cat *` in ssh.
Yonle's avatar
Yonle _@yonle.page.my.id 1 year ago
The nhttp server code is licensed under BSD-3-Clause. However, the nhttp endpoint / api / spec was being licensed under **public license**
Yonle's avatar
Yonle _@yonle.page.my.id 1 year ago
nhttp compatible relay is available to test at https://yonlecoder.lecturify.net NOTE!!: As it was using bostr, It's slow. Performance may be different when used in real relay software, which you could do by making nhttp server to connect to your relay and configure reverse proxy to forward /req and /publish path.
↑