First, we need to understand some of the basics.
What a Swarm is and what does it allow for. Instance of a Swarm allows for group connectivity in an untrusted environment. Untrusted? How so?
Imagine, we’ve got multiple peers willing to have a group meeting. Usually there are some computers either acting as intermediaries - meaning as full-blown servers, doing matching of peers and retransmitting data received from peer A to all the other peers involved. Usually, such a provider (Facebook, Skype etc.) is also able to see all the data passing by between participants.
We do not want that. We want the entire mechanism to be both decentralized - so that nobody ever has control over its operations, and - we want the service to be end-to-end encrypted at all times. So whenever another party is involved in data retransmissions, it has no way of knowing what these data packets actually contain.
As far as we are aware, the technology which we’ve been working on covers all these bases and it is the first technology of such a kind for cross-browser communication.
And indeed. What does it mean? Let us say a few words about the underlying WebRTC technology first, shall we?
WebRTC is now a standard for cross-browser communication, implemented by all the major players. Yes, your web-browser supports it.
So what’s the deal with signaling?
First off, as the above referenced Wikipedia page states:
The WebRTC API includes no provisions for signaling , that is discovering peers to connect to and determine how to establish connections among them.
In short - even though WebRTC may be used very effectively for cross-browser communication, it does not provide two things:
The lack of a signaling protocol is both good and bad. On one hand, developer has freedom of choosing /implementing the mechanics by himself on the other - that’s something that needs to be taken care of.
When you think of it, had it not been the case, and had WebRTC enforced a certain kind of signaling protocol, we would never be able to implement Swarms technology.
Oh, oh… but who’s to be operating that ‘signaling server’? Under whose control it’s gonna be?
Now we begin to see more and more clearly… the one who operates the signaling server, he is going to end up wielding power in his hands.
How? Show the signaling server go down - the entire service goes down.
Should a user be behind a firewall, an ‘administrator’ could cut the user out from accessing the service as well - Easily.
All other things held constant, relying on a single party to provide all the signaling services - Let it be for free or not wouldn’t be the most desirable form of making things work in a supposedly decentralized environment.
Decentralized signaling is needed also from a technical perspective.
What’s wrong with that? You might ask…
Well, we were after having group conversations, remember?
So, if Allice ends-up connected to signaling node N1 and Bob ends up connected to signaling node N2, how are the signaling datagrams be exchanged between Allice and Bob if, now fathom - N1 is entirely not aware of Bob and N2 is completely unaware of Allice to begin with.
Indeed, connections would be effectively established only among peers connected to the very same signaling node/server. There would be no communication between peers connected to different signaling nodes. Period.
The big news is that we have managed to change all that. We have made signaling datagrams traverse signaling node boundaries. Now, N1 would communicate to N2 all Swarm members he is aware of, and vice versa. As one may imagine, it is significantly more complicated than that, though.
Signaling nodes exchange most of the SDP datagrams when and as needed. That also holds true for the exchange of ICE candidates.
So, with our technology, Allice and Bob do not need to worry whether they end up being connected to same signaling node or not. Or whether a given signaling node is available from behind of a firewall, they happen to be obstructed by.