IPFS IPFS Camp 2022 - Libp2p Day, 1 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Browser connectivity state of the union and demo - Marten Seemann

Description

This talk was given at IPFS Camp 2022 in Lisbon, Portugal.

A

uh Steve has already mentioned: we are focusing on browser connectivity. We have for the last probably last year, I would say and I've, given a talk similar to this um about half a year ago at the P2P event in Paris and things look very different there. So this is the updated version with all the progress we've made in the last couple of months.

A

So as a very quick reminder, what what do we do? In lipidwby? We connect notes. These are point-to-point connections between two nodes and because there's no one-size-fits all as we will see nodes have different connectivity options and we use the concept of multi-addresses to um to to encode the addresses of nodes. So there you can see two two multi-adders is one for for a node, that's listening on Port, 10, 000 on TCP and then a quick listener on Port 20 000..

A

um All the P2P connections are secure. They are encrypted. There's no, no way to do unencrypted, lipido, p connections outside of like a testing environment. um What does it give us? It gives us that nobody can listen onto our conversations, and it also gives us the nice property that we know who we're talking to. We know the peer ID of of the remote we use noise and TLS to secure to secure connections like these are the two main options that that are available to lipidop nodes.

A

um Every lipidp connection is also stream multiplexed. Once we once we establish a connection and as we will see, this can be expensive in some in some situations we want to make good use of that connection and have multiple protocols um communicate in parallel. This is very easy when we use a protocol like quick that has streams on the transport layer, we don't need to do anything there, but when we use a protocol like TCP that doesn't have any screens, we apply a stream multiplexer to get to get a stream multiplexed connection.

A

So let's look at let's look at the options that we have available.

A

So, as I already mentioned, we have TCP and we have a quick and that works fine for Standalone notes like nodes that you would run on your computer or nodes that you would run in a data center go lipidop has has support for both for both qcp and quick and, as Microsoft said, Rusty PDP will merge, will merge quick support very soon, thanks to Elena for for her hard work on that.

A

Unfortunately, in the browser we can't just dial a TCP or a quick connection. Why is that? Under the hood, the browser, dials, TCP and quick connections, all the time like every time you make you make a request to a website? The browser will either establish a TCP or a quick connection and then run HTTP on top of that. But the browser doesn't give you access to the underlying connection. There's no browser API to say, like I, would like to have just the TCP connection, but without http.

A

This is done mostly for for security reasons.

A

So one option that we had is using websocket websocket is a pretty old protocol and it's been part of lipp2p for um multiple years. um I think very early on that was added.

A

Websocket is a protocol that allows the browser to establish an HTTP connection first and then basically convert that HTTP connection to a TCP back to a TCP connection like to a full duplex byte stream.

A

um This is possible via HTTP one and also via HTTP 2, um since since 2018.. So the way this works is you can you can use this this JavaScript there and type new websocket um and the URL, and the browser will then send a so-called upgrade request. It's a normal HTTP HTTP request with the upgrade header and if the server is willing to accept, accept this request and accept to speak a websocket on this connection.

A

It replies within like Hep 200 code and from then on everything sent on this connection um is not interpreted as hdp anymore, but it's just raw bytes and the both endpoints need to make sense of these drop bytes, which means we can in liquidity. We can just treat this as a normal normal, like TCP connection and run our handshake on top of that run, a stream multiplexer on top of that and get the properties of a lipidopy connection that we want.

A

We use the noise handshake to verify peer IDs um that works fine. It also means that that we'll do double encryption. If we have an underlying um secure, websocket connection, we have the TLs layer and then we have the noise layer on top of that. So that's not great for performance. It works.

A

um The big problem with the websocket, though, is that the browser will force us to do to do a secure, websocket connection. So what exactly is the secure websocket connection? It's basically the same as a websocket connection, but we are running on top of https instead of HTTP. So there's an additional TLS handshake happening at the beginning.

A

um Before before we before, we send our HTTP upgrade request, and this poses a big problem for us in lipidopy, because the browser doesn't only only require this connection to use some some certificate, but it actually enforces, as forces us to present a valid certificate like a certificate that was signed by a certificate.

A

Authority like like, let's encrypt, for example, but then, let's encrypt doesn't just give us, um wouldn't just give us a certificate for an IP address to get a a certificate from let's encrypt, you actually need a host name and most libido P nodes. Don't have a hostname, it's just something that you might spin up on your machine or on some some virtual server that you just booted booted up in some Cloud environment and you might not have configured a DNS server.

A

So getting a TLS certificate for for any lipido. P node is just not feasible.

A

There's some nodes where it is like our bootstrappers, like long-running notes, where you put in the time to do some manual configurations they can use websocket but for the average lipid to P node. It's not it's not possible and that's why websocket is like a French transport in in lipid2p.

A

The other problem with websocket is that it's pretty slow I did the math to calculate how long it takes to establish a websocket connection, and it's not pretty. You first spend a round trip on the TCP handshake. Then you spend another round trip on the TLs handshake. Then you do. The websocket upgrade request. It's another round trip. Then we are in the P2P land. Then we do a multi-stream negotiation of of our security protocol. Where we negotiate noise another round trip, then we do the the.

A

Then we do the noise handshake, another round trip, and then we negotiate the stream multiplexer. Yet another round trip. So we end up with six six round trips that hurts the only thing that we can improve. There is the lipido P part, so we we've been work actually working on eliminating those those two two round trips we spend on on this multi-stream negotiation. So we can, in principle bring this down to four rtts, but for our TTS is still a lot.

A

Okay, so to summarize websocket it's an option: it requires a certificate, it requires manual configuration, um but it's the it was the first protocol that allowed us to connect browsers to the lipidop network.

A

So a lot of time passed and then at some point, web transport came came along. It's a new protocol, that's now being developed by the ITF, there's no RFC. Yet um it's still um it's still in the in the process of becoming an Roc and probably that will probably take another year or two.

A

um It runs on top of HTTP 3, which means an HTTP 3 is running on top of quick by virtue of running on top of quick. It is always encrypted and it provides access to the native quick streams. So it's somewhat similar to to websocket, which gave you access to the underlying TCP connection in web transport. We get access to the underlying quick connection.

A

It also works like on the wire it's a totally different protocol, but conceptually it's it's quite similar. So you also say like in your web transport. You give give it the URL. The browser will send an HTTP request, so I can upgrade request.

A

That's encoded um totally different, but then the browser can accept this say yes, I'm willing to accept the web transport session, and then you can use native quick screens the security properties that the browser enforces are the same as websocket at least that's what we thought until the beginning of the year, but then the w3c, which is the the um um the the the standards body. That's that's standardizing.

A

The browser API introduced a new option uh and it's intended originally intended for short-lived virtual machine deployments, and these virtual machines basically have the same problem as lipido P nodes. They don't, they might not have a hostname and they also because they are so short-lived. It doesn't really make sense for them to to um to get a TLS certificate.

A

So what the w3c proposed as a browser API is, is what the browser could accept a certificate that is not signed by by a CA. If it knows the hash in advance.

A

So what what the browser does is it just establishes? The connection does the TLs handshake and then it checks. It calculates the the the the sharp 256 hash of the certificate and, if that matches the value that it expected, then it will accept this as a as a secure connection, so in in lipid2p we can just we can. We can use that. We already have multi addresses right and we can put stuff into multi addresses and we do this by just adding the hash of the certificate to the multi-address.

A

So now, if I give you a multi-address like this, you will know the port, the IP. You will know that it's web transport and you will know the the hash or the certificate, so your browser can establish a secure connection to me. There are a few caveats here.

A

um The the API says, like the certificate, must not be an RSA certificate. Okay, we don't care about this. We don't use RSA certificates anyway, but it also says the certificate must be short-lived, because this is only intended for these VM deployments. The certificate must not be longer than valid for longer than 14 days and if you try, if, if I set up a server with a certificate that is valid for like 15 days, the browser will say like nope I, don't accept this hand check failed.

A

So we need to work around this and we do this basically, by by having every node, generate multiple certificates and shipping, multiple multiple certificate, hashes and then, when a node is very long running. If it runs longer for like two weeks, we just generate a new certificate and update our multi-address and advertise that that updated multi-adders to the network.

A

So this all works. We ship this in the in the latest early b2p release. Currently it's it's an experimental status, um but we will probably make this um make this a default transport um soon.

A

So, let's count the round trips. Here we have one round trip for the quick handshake. We have another round trip for the web transport connect request and then we run another. We need to run another handshake, a noise handshake to verify the peers peer ID.

A

So, in total these are three round trips, um but we can probably get this down to two round trips. Currently, the browser API doesn't allow us to do um to to run the noise handshake in parallel to the connect request, but from the protocol specification this should be possible.

A

So now it's it's basically up to the w3c to to modify the browser API. So this is possible and I'm I'm hopeful that this will happen. I can't make any promises, but it's the it's a protocol and an API, that's still under development. So we can. We can influence this and we can probably bring down this handshake down to to adjust to rtts, which would be super great. Another thing I want to point out. We are running the noise handshake on a single stream, and then we can open more streams on this connection.

A

This means we don't need to do double decryption, because the noise, the noise part, is just limited to this one handshake stream and after that, all the other streams are just just encrypted ones with with as part of the quick connection.

A

So what are use cases for web transport? There are a lot of use. Cases for this, and I can probably not think of all of them, so I I need your help here. uh But I have I have a few ideas that I've listed here. um So so one one thing we could do is we could use.

A

um We could make make applications like glyph, um which are basically a way to send uh to send file coin transaction. We could make them a more decentralized currently, when you assign a when you send filecoin via the glyph, the glyph web interface, you sign the transaction and then this transaction is transferred via HTTP to like a proxy server, a Gateway server that that glyph is operating, and then this server is running like a full, full Falcon node and is broadcasting it to the Falcon network via gossips.

A

Now that we can connect any browser node to any girly P2P node, we could do that ourselves. We could just have a web transport connection to some storage providers or some other nodes in the Falcon Network and use JS gossip sub to to put the message into the the mempool directly another.

A

Another thing we could do is we might be able to to do to to make a file coin deal directly from from the browser could connect to a storage provider using web transport upload a file um do like all the all the stuff we need to do to to sign the transaction and do that without without any any other note being involved.

A

This might also be interesting to retrieve the data later on from any ipfs or any filter. Node and Alex will present uh present a short demo of JS lipid to P downloading a file from from a Kubo node. After this talk.

A

To summarize web transport, we shipped it in goli P2P it works. We can connect, connect any browser node to a go lipdp node in Rust. We we currently it's currently not yet possible because there's no web transport implementation in Rust, that's integrated into rest lipid2p. Yet so now, we've we've discussed how we can connect browser nodes to server nodes or Standalone nodes in the network.

A

There's one thing that we can't do with this set of protocols yet which is connecting um connecting browser nodes to other browser nodes and also connecting browser nodes to um to nodes that are behind firewalls.

A

That's why we are working on webrtc webrtc is a pretty old protocol. It's it's been standardized in 2014 and it's immensely complex like if you try to read the rfcs, you have a list of like 100 rfcs. You need to read to to understand. What's going on there, it's really not fun.

A

It's built for audio and video conferencing and I'm. Sure everybody here in this room has used it many times when you do a zoom call. When you do a Hangouts like any any of those video conferencing tools, we'll use webrtc under the hood.

A

um We don't need all this audio and video features, but there's also a a reliable, um reliable data channel uh called the RTC data channel in in webrtc, and we can use that to layer lip P2P streams on on top of those if you're interested they they are using sctp over dtls over UDP. So that's so some keyword keywords to start your RFC search. If you want to laughs.

A

Webrtc also because it's built as a peer-to-peer, video conferencing, video conferencing protocol allows certificate verification by certificate hash like when you, when you join a zoom call, you don't need to get a TLS certificate right, um so that works, and it also provides a hole, punching capabilities. So you're you're able to to establish webrtc connections if you're in your home network and your router is blocking incoming connections.

A

um We so so we we, we um split the the webrtc use case into um basically. Basically, two parts, one is the browser to server, uh and one is the browser to browse for the browser to server.

A

um We built a protocol on top of webrtc that doesn't require any stun and turn servers. There are more keywords for RFC searches um and we do we do an additional. uh We do additional noise handshake there. uh The lip P2P specification is almost done, and we also have implementations in in JavaScript in go and in rest that are pretty close to getting merged, but they are still in in review.

A

Let's count the round trips here: um first, we need to do a stun exchange. Then we need to do a dtls handshake which takes two round trips. Then we need to do the sctp handshake, which takes another two round trips, and then we need to do our noise engine. So we are back to six round trips here um so the same as websocket.

A

It's not great, but it works, and if that's your only option, um then you would you would be willing to wait six rtts if the, if the alternative is to have no connectivity at all. On the other hand, if you have the, if you have the option to do web transport instead of webrtc, you would of course choose that then for the browser to browser part. It's currently just a draft draft specification.

A

We are working on it.

A

um I don't want to go too much into detail here, because Max has another talk about about webrtc in in particular, uh we are using our circuit relay V2 servers as coordination servers, and this will this will enable able browser to browser connectivity.

A

So what what are the use cases, as I already mentioned, um for the browser to server use case? It's a fallback when web transport doesn't work and for browser to browser we can. We can potentially exchange files directly between two browsers, which is cool and maybe verify in the future. We are not currently working on this.

A

Just an idea might be helpful for for in in for in mesh Networks that don't have any connection to the internet so that completes our connectivity table um webrtc, as I mentioned it is, it is in progress, it will be, it will be done very soon and uh stay tuned for updates there, and if all of this sounds very complicated and confusing to you, don't worry it is that's why we launched a website, connectivity.lib p2p.io.

A

It explains everything and a lot more um in in great detail, so you can can head there and and really read, what's going on, if I'm, connecting a standalone node to a standalone, node or browser node to a standalone node, and all these all these different combinations, I explained there. So you can, you can read it up.

A

Yeah. Thank you for your attention.