You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was looking for a way to provide a fullsome and complete implementation of the http application layer protocol service in libp2p using libp2p streams as the transport.
I decided to create the plugin myself by forking libp2p and putting it in the packages under protocol-http
I've built this, it seems to run well and it even provides websocket upgrades over libp2p streams. It strictly complies with http 1.1 spec and the interface it provides to the developer is the same one provided by nodejs.
This means it is event driven and porting a webservice to libp2p should be simple now. For simplicity sake the whole thing is just using protobuf and it's working fine with yamux.
There's a webserver "listener" that is peerId based and there is a fetch compatible component so your browser app can fetch('http://peerId/some/endpoint") and you can treat the whole thing like any other webservices connection, even though it is transport layer agnostic.
Basically, I wrote something to strictly comply with the official libp2p-http spec.
Honestly, I'm not sure where to go from here. I don't necessarily want to maintain this long term, but I'm willing to be the maintainer of it for the time being.
Just to be clear (and for future readers/issue spelunkers), the HTTP spec is "libp2p streams over HTTP" and there is an existing js implementation of that here, whereas what this issue appears to be about is more like "HTTP over libp2p streams".
I was looking for a way to provide a fullsome and complete implementation of the http application layer protocol service in libp2p using libp2p streams as the transport
I would take a look at go-libp2p-http which has a similar goal of "HTTP over libp2p streams".
Instead of implementing a full webserver/proxy/websockets/etc stack it just provides the underlying streaming primitive (e.g. a libp2p stream instead of a TCP socket) and lets existing webserver implementations do the heavy lifting.
To do something similar in js you may be able to use it-to-stream to turn a libp2p stream into a node stream, then use the http module in node and something like stream-http in browsers, ws for WebSocket support, etc.
This approach is vastly more maintainable and you'd then also get compatibility with application frameworks like fastify, express, etc for free.
I was looking for a way to provide a fullsome and complete implementation of the http application layer protocol service in libp2p using libp2p streams as the transport.
I found an official spec at https://github.com/libp2p/specs/tree/master/http but I noticed that there had been no action in over 5 months.
I decided to create the plugin myself by forking libp2p and putting it in the packages under protocol-http
I've built this, it seems to run well and it even provides websocket upgrades over libp2p streams. It strictly complies with http 1.1 spec and the interface it provides to the developer is the same one provided by nodejs.
This means it is event driven and porting a webservice to libp2p should be simple now. For simplicity sake the whole thing is just using protobuf and it's working fine with yamux.
There's a webserver "listener" that is peerId based and there is a fetch compatible component so your browser app can fetch('http://peerId/some/endpoint") and you can treat the whole thing like any other webservices connection, even though it is transport layer agnostic.
Basically, I wrote something to strictly comply with the official libp2p-http spec.
Honestly, I'm not sure where to go from here. I don't necessarily want to maintain this long term, but I'm willing to be the maintainer of it for the time being.
Would it be uncouth to just open a PR from my feature branch?
https://github.com/syntropiq/js-libp2p/tree/feature/protocol-http
It's an embarrassingly bad commit history but at least it's clean and doesn't touch any other parts of the stack.
Or is there some other process it needs to undergo?
Thanks in advance!
The text was updated successfully, but these errors were encountered: