Re: Thoughs about communication

[Matthew Hodgson <matthew matrix org>]

On 27/01/2017 16:07, Simon McVittie wrote:
> As an ex-Telepathy developer, it's interesting to see the focus
> swinging back towards bridges. One of the motivations for the design
> of Telepathy was that XMPP claimed to have the same multi-protocol
> advantages as Matrix, via bridges; but in practice (at least at the
> time Telepathy started) those bridges often didn't work very well,
> and they certainly didn't have "first class citizen" support for
> those other protocols and their quirks. In practice they usually
> ended up supporting the intersection of XMPP and the other protocol,
> with a weird UX (like talking to
> example%hotmail com msnbridge example com).

I think it's fair to say that we've tried to make bridging more of a 
first class citizen in Matrix than it is in XMPP (even the name Matrix 
is meant to allude to matrixing together different networks :)

However, it's inevitable that there's always going to be an impedance 
mismatch between the protocols.  We try to fix this by giving Matrix's 
core federation protocol the minimal set of primitives you can use to 
express higher level behaviour.  Meanwhile the actual data transferred 
can be anything you like (albeit with some schemas defined by the 
standard for IM, VoIP, file transfer, etc).

That said, we've already hit some limits on bridging semantics - e.g. on 
the IRC bridge, we directly bridge messages seen on an IRC channel 
through to the mapped room on Matrix.  But some ircds support 
chanop-only messages in a channel, leaving us with a dilemma on Matrix 
as we don't support per-message ACLs yet (although it's planned). 
Similarly, Matrix's bans currently only act per-user, rather than the 
exotic set of per-hostmask/ident/IP/nick that ircds support.

So, our attitude is to try to expose the richest possible set of 
semantics over the bridge, but accept that it's never going to be 
perfect.  If you want to do some exotic IRC ban on the IRC manifestation 
of a conversation, then it's time to fire up an IRC client (or inject it 
as raw IRC via the Matrix bridge).

> Telepathy never actually reached its potential for
> first-class-citizen support for protocols other than XMPP either,
> unfortunately. The majority of paid development time went into the
> commercially-relevant protocol, which at the time was Google Talk's
> dialect of XMPP, and the protocols that weren't part of anyone's
> product just didn't keep up.
>
> There was also the problem of impedance mismatch between protocols,
> which bridges and libpurple seem doomed to suffer too. Parts of
> Telepathy are as weird as they are specifically so it could support
> quirks of a particular protocol, like IRC (unique identifiers are not
> persistent, presence subscription doesn't exist), XMPP (chatroom
> names are meaningful to humans, except when they aren't), MSNP (a
> private conversation is just a chatroom that happens to only have two
> participants), SIP (there is presence but it's (claimed to be)
> patent-encumbered), ...

It's worth noting that Matrix handles all of the mismatch examples given 
there okay - or at least doesn't make them any worse; they are all 
'perimeter mismatches' due to limitations of the remote protocol, but 
can be expressed okay over Matrix's common language.  (For instance, 
Matrix does the MSNP thing of making even 1:1 chats a room that happens 
to have 2 participants, rather than making the more limiting and 
opinionated choice that 1:1s are an entirely separate primitive).

> > Trying to support 20 different protocols really took its toll on
> > the Empathy user experience. Requires manpower.
>
> I'm not sure that trying to support the same number of protocols via
> bridges would actually make the UX any easier; but I can see that
> having a small number of explicitly-supported protocols, and leaving
> the rest requiring manual setup or tolerating a weird UX (or both),
> would probably help.

A big difference between Matrix and the libpurple or telepathy (or haze) 
approach to multiprotocol support is that Matrix obviously does the 
bridging serverside, and we've tried to make it as simple as possible. 
For instance, a basic Slack bridge is about 100 LOC:

https://github.com/matrix-org/matrix-appservice-bridge/blob/master/HOWTO.md

So hopefully it's possible to build out quite a huge ecosystem of 
bridges for different protocols; for instance in the last month we've 
seen community contributions for iMessage, Telegram (3 different impls 
in different languages), Gitter and more.  We also have a fledgling 
matrix-appservice-purple which goes and wraps up libpurple itself as a 
Matrix bridge (and supports Skype) - although that one is in need of a 
maintainer :(

Anyway, hopefully this gives a bit more context on where Matrix's 
bridging is headed (apologies if we're getting off-topic...)

M

--
Matthew Hodgson
Matrix.org