NIP-200: Nostr Over HTTP(S) (NoH)

[Yonle]

This NIP describes the basic of communicating to relays over HTTP(S) requests.

Potential use case:

• Weak or slow network environment

Implementation:

• nhttp: https://github.com/Yonle/nhttp (RoWS [Relay over WebSocket] to NoH [Nostr over HTTP(S)] converter)
• nhttp-adapter: https://github.com/Yonle/nhttp-adapter (for using NoH compatible relays in incompatible client)

[This doc still require some improvements]

[jb55]

Weak or slow network environment

why would this be better than websockets?

[Yonle]

Weak or slow network environment

why would this be better than websockets?

• There are times for gzip to be able to compress the text
• There are environment when idle TCP connection is not really did well (eg. Constant disconnection)
• There's no need for sending CLOSE after receiving lots of events. In websocket, you may still receive number of events even after sending CLOSE due to TCP nature

Above of that, Just to allow it being possible to communicate not only in Websocket. That's as far as i could tell.

[vitorpamplona]

There are times for gzip to be able to compress the text

Compression is supported on Websockets as well.

The main difference is that each event is a separate package in WebSockets. The payloads are quite small. With HTTP, the entire filter is returned at once in a massive string.

Both APIs might use the same filter spec, but the way to use this interface is not the same as the WebSockets one.

[fiatjaf]

The alleged benefits definitely do not justify breaking compatibility.

[Yonle]

Aside of having the alternative way for communicating with nostr relays, NoH do not rely on REQ subscription limit, which should solve some relay REQ limit problem that nostr client dev have faced.

Doing a quick REQ and then doing CLOSE at big query is not really effective, and just recommending user to change relays or ISP don't really solve the problem.

[mattn]

This specification can not be recognized EOSE. If there is a way to reduce transfer size using the HTTP-based method, it is chunked streams, I think. This is PoC.

https://github.com/mattn/nostr-relay-http-chunk/

This HTTP server provide endless HTTP chunked stream.

[Yonle]

This specification can not be recognized EOSE. If there is a way to reduce transfer size using the HTTP-based method, it is chunked streams, I think. This is PoC.

https://github.com/mattn/nostr-relay-http-chunk/

This HTTP server provide endless HTTP chunked stream.

This is great. We could also put this as a feature for receiving events in real time. As it does not need EOSE, Disconnecting the HTTP server also equals closing the current subscription entirely.

[Yonle]

I think /stream could replace /req endpoint. Any thoughts?

[ocknamo]

In my opinion, I also don't think it would be very useful to recreate all the relay behavior in HTTP.
However, some kind types may benefit from proxying to the HTTP protocol to make caching more effective.

For example, unlike kind1, kind0 events are not changed or added frequently, so a model that acquires data in a stream is not suitable. In this case, WebSockets are difficult to cache, but if you proxy to HTTP, you can effectively use a CDN's edge cache etc.

I was told recently that such an implementation already exists.

https://api.yabu.me/

It would be useful if it were standardized.

However, since I am only talking about "read", I think it is appropriate to call it like Nostr proxy to HTTP.

[Yonle]

In my opinion, I also don't think it would be very useful to recreate all the relay behavior in HTTP.

This feature is entirely optional for a relay software to work.

However, since I am only talking about "read", I think it is appropriate to call it like Nostr proxy to HTTP.

As it was supposed to be also able to talk to nostr relay via HTTP, It's not rather just an proxy so i will leave the name as is.