Oddbean new post about | logout
 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

https://github.com/Yonle/nhttp 
 Idk whenever i should create NIP for this.


Probably no. 
 Similar to Nip-98..  
 That was different thing. 
 Time to code the nostr relay adapter for nhttp server. 
 It makes sense to me, thanks for trying this. Websockets is just one possibility IMO, for some use cases other protocols can be a better choice. I'm looking forward to the new possibilities we'll create. 
 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. 
 This should be a feature in #nostr relay software instead of being like "http-only nostr relay". 
 很早之前就看到有对 Nostr 通讯使用协议的争论. 虽然 nips 中的设计默认都是 WebSocket, 但是看起来实践后也有很多人想在某些使用场景下使用 HTTP.
nostr:nevent1qqs84gugquq605e8nuqtk8eqr7tz6dxsgzpaz8uuaesseeee9sgfgfqpz3mhxue69uhhyetvv9ujumn0wd68ytnzvupzqdr6ydcfqrgeknj82c3pt98ghknsdtju0pw7p8jeu3s9lydq8ayuqvzqqqqqqyqcge5u 
 The nhttp server code is licensed under BSD-3-Clause. However, the nhttp endpoint / api / spec was being licensed under **public license** 
 nhttp software is ready for production use.

Adapter is available to use nhttp implemented relays in nostr clients: https://github.com/Yonle/nhttp-adapter 
 Nostr over HTTPだそうです
nostr:nevent1qqs84gugquq605e8nuqtk8eqr7tz6dxsgzpaz8uuaesseeee9sgfgfqppemhxue69uhhjctzw5hx6ef0qgsrg73rwzgq6xd5u36kyg2ef69a5ur2uhrcthsfuk0yvp0ergplf8qrqsqqqqqpsckt9k 
 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. 
 👀
nostr:nevent1qqs84gugquq605e8nuqtk8eqr7tz6dxsgzpaz8uuaesseeee9sgfgfqpremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59upzqdr6ydcfqrgeknj82c3pt98ghknsdtju0pw7p8jeu3s9lydq8ayuqvzqqqqqqyq9z64g 
 After several test, nhttp and it is adapter is ready to use. 
 NIP-200 proposal has been opened.

https://github.com/nostr-protocol/nips/pull/966