-
Notifications
You must be signed in to change notification settings - Fork 18
Other signaling strategies #14
Comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Ah, ok. So to clarify, you need decentralized signaling on both the JS and Go. Part of my experiment was to find something that solved the same. There is a current bug preventing go-ipfs from talking to js-ipfs, but in general IPFS pubsub is the only solution I have found in this space. The only other thing I have considered is building a Go version of gun. Otherwise, there are other DHTs (e.g. bittorrent mainline) mutably available from Go, but the JS side can't write to them. Also, in general I'd like to see a signaling abstraction project that provided a common API and a collection of signaling backends (not specific to decentralized or anything) that a dev could leverage. I personally moved to centralized a system like https://www.websocket.in/ after realizing there are no easy decentralized ones (I don't want a 600+k js-ipfs blob if I can avoid it and it was struggling to communicate w/ go-ipfs at the time of my experiment). EDIT: I should add I have had recent success using https://github.com/amark/gun for signaling. I'm not sure it applies to a libp2p project though, it's more of an alternative than complementary. |
So I've been um'ing and ah'ing over this for the last week, and I have some thoughts to throw into the pile. And a suggested way forward... I want to start by noting that the ultimate problem here can be framed as: PeerA and PeerB exist but can only run web browsers. PeerA wants to create a WebRTC connection with PeerB. We need some way of getting a message to PeerB. This is the ultimate desire, even though we call it "signalling". Any solution here only makes sense if people will actually use it. Key attributes would be:
So let's simplify this discussion be removing a few options:
Of the remaining options, they can be split into two buckets as follows: Decentralised
Semi-decentralised Decentralised Unfortunately, I think we have to disregard decentralised signalling for now. IPFS is an awesome decentralised network, and @cretz has done awesome work, but is pubsub ready for primetime? Is it possible to code? Is it sufficiently reliable? I'm unconvinced. Tor is an interesting option. It allows us to pass messages between two peers. But will Tor allow to web browsers to pass messages between each other? It would need to have HTTP/WebSocket entry points. Are there other options here? Semi-decentralised I am warming up to this idea. The two options above are more similar than we give them credit for, but they ultimately fail on two aspects:
Potential solution I think the easiest way to phrase this is to do something like libp2p/js-libp2p-webrtc-star with a few important differences that make it far more desirable to operate free and open signalling servers:
|
If you're in the Tor browser, there are some opportunities, but not much more than a regular browser. I have a PoC that might interest you though it's outdated and there needs to be an app side somewhere: https://github.com/cretz/tor-dht-poc |
Wow @cretz, is there anything you haven't done?! The thing is that we would want Tor to be access for a regular browser. |
@rob-deutsch I agree with your thoughts above. It would be interesting to create a super strict, minimal version of SDP. Some thoughts:
|
Could the Here is how that would work:
The |
@SkyBeastMC It seems the message DialMe {
message Peer {
required bytes id = 1; // peer id
repeated string addrs = 2; // a multiaddr to dial the the peer over
}
optional Peer peer = 1; In order to exchange ICE info we need:
|
Oh, I forgot Peer A needed Peer B's SDP answer as well. |
Maybe we can add it to the spec discussion. |
@rob-deutsch I'm not sure that it's possible to standardize the SDP dialog. There will always be user-controlled bits in the SDP, hence the signaling server could always be abused into transferring arbitrary data. It might be less obvious, which is not much, but it will also have higher bandwidth overhead, which will might deter attackers. Anyway, in my opinion, a metered-per-peer signaling service should solve this exploit in a more elegant way. Also, what about forwarding messages in exchange for POW? 👀 |
The go-webrtc-aside-transport implements signaling over another transport. |
I'm super interested in using this software (https://github.com/libp2p/go-libp2p-webrtc-direct, https://github.com/Jorropo/go-webrtc-aside-transport). For my use case, I want to establish a connection between two servers that are both potentially behind NAT. For me, routing application traffic through a relay circuit defeats the purpose. However, in my use case it's reasonable to assume that a semi-trusted relay circuit exists for the purposes of exchanging Session Description Protocol (SDP). I also want to establish a connection between a browser and one of those servers, but that's less important to me initially. I know it won't work If neither of them can get a public listening port (for example, via upnp), and/or one of them has an inscrutable NAT/firewall. But I'm hoping I can get it to work for the majority of users who are on reasonable "home" networks, for example, not dorm WiFi, not LTE hotspot, and not restrictive corporate firewall. |
We have a spec for a direct connection upgrade over Relay: which has been implemented at: We are also currently exploring the idea of "limited Relays" which meter the bandwidth and time you can use them for (should be just about enough for co-ordinating a hole punch/signalling). Would be great to use something similar for the signalling so we don't rely on direct HTTP connections. |
@aarshkshah1992 Are there plans to 'abstract' the signaling? AKA have the signaling path be injected into transports that require it. That would allow protocols that need signaling to be developed separately from all potential signaling paths. In the case of this repo it would mean we only need |
@backkem None for now but will very much keep this in mind when we get to working on decentralised signalling for WebRTC. |
I think it also possible to connect browser node to non-browser node with public IP without any signaling by generating answer SDP. It only requires TLS fingerprint which could be part of address. |
go-libp2p-webrtc-direct
contains the first step towards WebRTC support in go-ipfs: a port of js-libp2p-webrtc-direct which is the simplest WebRTC transport on the JS side. The drawback of*-libp2p-webrtc-direct
is that the signaling is done over HTTP. This requires a direct connection between the peers and therefore can't make use of WebRTC's NAT traversal capabilities.This ticket aims to explore other signaling strategies. For example, strategies that would also work when both peers are behind a NAT. I think it would be preferable to explore strategies that work across libp2p implementations.
'Centralized' signaling
Signaling over connected peers
The text was updated successfully, but these errors were encountered: