-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 29/06/15 12:36, Paul Hänsch wrote:
On 2015-06-25 16:18, Paul Hänsch wrote:
[see below]
.... I accidentally sent this mail only to Daniel at first and he has been so kind to point this out in his reply. I'd like to take the discussion to the list again. Daniel countered some of my points, maybe he could take this reply to the list as well. The field in general is very important to me, which is why I couldn't let it go even after so many weeks ;-) ....
On 2015-05-31 14:44, Daniel Pocock wrote:
On 31/05/15 12:12, cyberesprit wrote:
Don't forget the TOX project (no servers, all encrypted data,
I too think that we have to step beyound federation to a truly distributed network. As far as I can see TOX looks most promising in that respect.
"no servers" is not accurate. The DHT Nodes are effectively like servers in SIP or XMPP networks:
What you link to is a list of bootstrap nodes. Other than servers those are only importent for a client to initially join the network. Once it has learned of other nodes, they may fade from the peer list. In a federated network you commit yourself to the use of one provider, which will then become a hassle to change (e.g. people still send me mail on very old mail accounts). In a distributed network the nodes you communicate with are arbitrary which decreases the amount of power in the hands of service providers by an order of magnitude (in addition to the decrease that happens when you federate a centralised infrastructure).
I agree that a distributed solution is better for personal communication, but for organizations, especially larger ones, it is not clear they will take to that.
When I refer to organizations, I'm not specifically referring to service providers, rather, I'm thinking about those who are large enough to run their own mail server or something already.
If you really believe in TOX for RTC, then you also need to be able to answer the question, will this work for email too? Do you see organizations moving from SMTP onto a distributed topology? So far, SMTP has probably been the most successful of federated technologies and no one provider has been able to lock out the small guy.
In fact, if you look at the distributed version control solution Git, it uses email addresses, which come from the world of federated SMTP, as user ID. Yet Git works in a distributed way.
While there are several interesting solutions like this (TextSecure was another example) they are not getting traction in organizations like large companies, universities or public bodies. SIP and XMPP may well be the only open solutions having the right profile to serve institutional needs.
Providers of highly centralised solutions assert the same for their respective services with just as little substance. That's a blatant claim.
In fact Skype used to cover this field quite well, when it was still a highly distributed protocol. A pity that the vendor enforced single control points that were purely artificial and not strictly necessary for the technology to work. A pity that it was never open.
Skype never seriously took on large corporate phone systems. It is only ever an alternative that users install for private use.
There are also proprietary solutions trying to service those institutions: Microsoft Lync, Google Hangouts, vendors like Avaya offering products that claim to do SIP but only work with other products from their approved partners.
Sooner or later, I can imagine Facebook, LinkedIn and Salesforce all offering their users WebRTC too.
Like they offer XMPP today - in a way that has nothing at all to with federation or user independence.
Actually, that is what I meant. WebRTC doesn't imply federation at all. It doesn't provide any signalling channel at all in fact. So you can use it with (a) distributed protocol, (b) federated protocol or (c) walled garden. I would argue that (b) is better than (c) and we seem to be in agreement that those corporations I named would choose (c) by default.
Just as Google dropped XMPP support, I doubt any of those vendors will be keen to enable federation or interact with open source clients if they can avoid it. The only thing that will make them consider remaining open is if some large organizations or public bodies do actually deploy standards-based SIP and XMPP.
They *are* the large organisations. They became so large *by* locking in users. The last thing we need is an even more powerful one for them to submit to. We as users must escape this powerplay among giants. We can do so by dwarfing them in comparison to an infrastructure that doesn't require giants to run. While federated providers can grow into giants, like Gmail did for email, distributed networks keep all their users at eye level. They can only grow as a network while no participant can increase his share over the system or even cut off all others.
As I commented before, I'm not talking about federating ISPs. I'm talking about other organizations that are already capable of running their own SMTP server, for example. Many companies still run mail servers even though they could use Google Apps. If lots of these small to medium organizations do deploy XMPP and SIP, then the bigger providers may tolerate it the way they do with email.
The control points of WebRTC do not only lie in the TURN servers and confrence proxies, they even start with the web interface which a provider delivers to its users. If the server software is Free Software I can become my own provider. But if the giants won't peer with me, I can only try to become another giant, or submit to one and and stay the dwarf. Only a distributed technology put's me on eye level.
I'd be quite happy for you to submit a patch to JSCommunicator adding support for a distributed signalling protocol. It would be completely valid for people to have some choice in the UI allowing them to use SIP, XMPP or some other protocol. The UI can then inform the user of the relative privacy and security for each call they make.
WebRTC is a revolution to the depressing void before which we stand in regards to video telephony. I think it has a little more danger of beeing sucked up by a large provider than SIP and XMPP, ironically that will also be the incentive for those players to aid in its development and distribution. I'm happy to see systems like WebRTC getting adopted, and it's good when FSFE doesn't stay behind there. My vision however would be that people communicate without the aid of distinct providers. Incidentially, in FSFE that would also mean less services to maintain for the system-hackers ;-)
The services being discussed are relatively lightweight compared to a full Asterisk server and are even easier to maintain than a modern SMTP server.
Regards,
Daniel