better motivation for libp2p+HTTP #515
Conversation
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 |
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.