References

• libp2p/HTTP Spec PR - https://github.com/libp2p/specs/pull/508
• Defining /http - https://github.com/multiformats/multiaddr/issues/63
• Define /httppath - https://github.com/multiformats/multiaddr/pull/164
• Fetch is not full duplex - https://github.com/whatwg/fetch/issues/1254

Implementation notes

• HTTP could be a js-libp2p transport, or if too far from the existing connection/stream conventions, a convenience wrapper similar to @helia/verified-fetch
• Transports return a Connection that can have streams opened on it
• Each stream could be a separate fetch request?
• Closing the connection would abort any in-flight fetch requests

Questions

User expectations

libp2p treats all transports equally. With the exception of limited connections over relays, the API is the same between WebTransport, WebRTC, WebSockets, etc. If the HTTP transport imposes arbitrary restrictions, users should be notified clearly and loudly to prevent them becoming surprised when it doesn’t “just work”.

Solutions?

• Throw errors if a write occurs after read?
• Protocols opt-in to running over HTTP? (see below)
• Omit protocols that haven’t opted in?

fetch does not support bidirectional streaming

• A request must be written in full before the first byte of the response can be read
• Once the first byte of the response is read, no further request bytes can be sent