more communities for federated RTC?

[Daniel Pocock]

-----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:
>> 
>> https://wiki.tox.im/Nodes
> 
> 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVkSiHAAoJEOm1uwJp1aqDyeQQALwZnXww6SeNB/hv4Ox1+GAZ
cmICMYWlD1obrLIYBNs1DzA1zW2uPnw0H/ybr9tLMFRQfTM9rjBwPNAMGlKkBUFM
9ch2SuNb+YU06g+Y0lgsMRFzHi/HFDZ4yiKADcoRRT/hamMvLkirA1QHLFQ+w/JP
rXsx8a4tg8Gr9rOUNpnsPQ67qPTMOT0J3yI462WGKyYG6eNRGpmppSc7MInIuhZm
iwaOKzmNtLMG92Lev+tXHsrCpBsfSZG/zWVW3FRjMsw90i2u9QgEN7IsGY/nu+Dw
nFcc41ZKI+g7aILAFt9BPtCzP67TJoO+tVs/RODtwtUt+iIQB/dTgNXlMAM2OJrZ
26v56qrJFdA1hSdzE3Ss3Fu1vBhvvK+QpGU8btS+yjxf6m6fvorgFKSzOxZuOTk/
OqBqXXg14qXvbpzkDuEpOCkq9mZnfKLowERuxY0dEA+8nDzNLqRd7QxdLMT1Pzm2
wFCUcCTCKKoStyXflx70K0yCk0bENQ3HUNK05pJHhCXwDqrYtFA9qCutBVgJeE86
wBZ09/UMHRy66q+OePWwdxikBcICIKfKKHv3F3shY8sdOh9dFODWqSWDMZUfuGDa
0s3d1Z27BQ858yLy7qTbnFOzTrN1aLjPStoSwE2CLi6HpDm7s4v4txb8fXagrCmj
q2m9mW7DdpyxVCwc1eEU
=HAaC
-----END PGP SIGNATURE-----