better motivation for libp2p+HTTP #515
Conversation
http/README.md
Outdated
| @@ -19,6 +19,14 @@ At the same time, nodes that are already connected via a libp2p connection, will | |||
|
|
|||
| Any protocol that follows request-response semantics can easily be mapped onto HTTP (mapping protocols that don’t follow a request-response flow can be more challenging). Protocols are encouraged to follow best practices for building REST APIs. Once a mapping has been defined, a single implementation can be used to serve both traditional libp2p as well as libp2p-HTTP clients. | |||
|
|
|||
| Specifically, using libp2p+HTTP will allow: | |||
|
|
|||
| 1. HTTP servers to offer same endpoints over HTTP and libp2p streams, allowing clients to reuse existing libp2p connections | |||
There was a problem hiding this comment.
Is this a main selling point? I don't care if I have 2 connections vs a single one. Although I guess the reduced latency could be good.
There was a problem hiding this comment.
Definitely not. I'll move it down the list.
There was a problem hiding this comment.
Actually, I'll just remove it.
http/README.md
Outdated
| Specifically, using libp2p+HTTP will allow: | ||
|
|
||
| 1. HTTP servers to offer same endpoints over HTTP and libp2p streams, allowing clients to reuse existing libp2p connections | ||
| 1. Defining services / protocols that are run on both public nodes and on nodes behind NATs / firewalls, making use of libp2p's NAT traversal magic |
There was a problem hiding this comment.
And leverage libp2p's connectivity story.
| 1. Use existing peer and content discovery mechanisms to advertise HTTP-enabled multiaddresses, which can then be accessed either via plain HTTP(S) or via HTTP on top of libp2p | ||
| 1. Use peer authentication (both client and server auth) for a subset of HTTP endpoints | ||
|
|
||
|
|
There was a problem hiding this comment.
| 1. Support edge compute directly. Many edge compute environments build on top of HTTP since it's a stateless request/response protocol. This includes services such as Cloudflare workers, AWS Lambda, Netflify Edge functions, and many more. |
| 1. Defining services / protocols that are run on both public nodes and on nodes behind NATs / firewalls, making use of libp2p's NAT traversal magic | ||
| 1. Use existing peer and content discovery mechanisms to advertise HTTP-enabled multiaddresses, which can then be accessed either via plain HTTP(S) or via HTTP on top of libp2p | ||
| 1. Use peer authentication (both client and server auth) for a subset of HTTP endpoints | ||
|
|
There was a problem hiding this comment.
| 1. Support existing HTTP protocols like the S3 protocol. This would allow peers to fetch content seamlessly from an S3-compatible provider (S3, backblaze's B2, Cloudflare's R2). |
For example, I imagine us shipping the S3 protocol support as part of go-libp2p. Then the provider records could include something like /dns4/someS3Provider/https/s3/. A client will see that provider when doing a content route lookup, and then be able to get the data directly. This could be piped to some other function that will verify the content hash.
There was a problem hiding this comment.
This and the below point are the things I'm most excited about. Having edge DHT nodes would be really cool
marten-seemann
force-pushed
the
http-motivation
branch
from
5a1343c
to
bbe02b3
Compare
marten-seemann
force-pushed
the
http-motivation
branch
from
bbe02b3
to
83d4499
Compare
No description provided.