|
On 25/08/2017 18:51, David Woodhouse wrote: On Fri, 2017-08-25 at 17:43 +0100, Matthew Hodgson wrote:Just to be clear, Matrix is *not* trying to be a one-protocol-to-rule-them-all, any more than libpurple is trying to be one-API-to-rule-them-all. Matrix is just doing the same thing: abstracting multiple networks behind a single API. The difference to libpurple is that the abstraction happens serverside by default rather than clientside. (Although we do have matrix-appservice-purple, which uses libpurple serverside as a way to bridge to other networks, a bit like bitlbee but talking Matrix on the frontend rather than IRC).What is the user experience here? Not like users being expected to do something "a bit like" setting up bitlbee, one hopes? :) Correct, it's nothing like running a Bitlbee. The typical starting point is to use an existing hosted bridge to the protocol of your choice that someone is running (e.g. matrix.org or disroot.org). Obviously this means trusting that server with your account on that network, but one can always go and run one's own (which means running your own server & bridge somewhere - similar complexity to running an ircd + ircservices). If you're using an existing bridge, the easiest bet is to use an app like Riot which has UI for discovering chatrooms & users on bridged networks. For instance https://matrix.org/_matrix/media/v1/download/matrix.org/CYonYNicRBvaiBwzKiuQUjSc shows a screenshot of the available bridged networks on the matrix.org server (a mix of IRC and Gitter for now). There is also UI to go and provision a bridge through to a specific Slack or Twitter feed. So the end result is that you end up with always-on connections to the various networks, provided by Matrix acting as a decentralised bouncer on steroids, with a very simple HTTP API (better transports are welcome though) for interaction, which any app could use. My proposal is that one could run a background daemon on Linux
which brokered the connection to your Matrix server (and perhaps
handled fun stuff like clientside history persistence, e2e
encryption voodoo, WebRTC audio playback/capture etc) and then
expose that as part of the OS to desktop apps - effectively as a
next gen telepathy equivalent. (And yes, such a daemon could be
extended to natively talk other protocols than Matrix if desired). If I've got this shiny new Matrix-replaces-Telepathy GNOME system, and I want to add a new account with a new protocol... what do I need to do? Let's assume I've just installed the appropriate distro package, and want to take it from there. (Although do feel free to talk about how it auto-installs the correct protocol package on demand, if you prefer). Hypothetically: you'd do as per the above; install a package for a client like Riot; point it at a server which is providing a bunch of bridges (or go hunt bridges on other servers); or go run your own bridge on your own server. For some bridges you need to login/identify (which is handled on a per-bridge basis currently) - the naive approach some bridges take atm is to do it a la Nickserv (i.e you have a conversation with a bot); in future there will be better reusable OAuth style UI for logging in. I should point out that Matrix is still in beta (especially
bridging), though, so I'm not claiming it's a universal solution -
and I really do agree that having libpurple and similar around too
clientside makes sense. But having access to a decentralised
encrypted comms network from the OS does also feel like a useful
primitive to have available too :) M -- Matthew Hodgson Matrix.org |