Re: Thoughs about communication

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:

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...)


Matthew Hodgson

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]