Re: Matrix as a replacement for Telepathy
Hi Rob, Thanks for the epic braindump here. I think that some of your caveats here may be more relevant to telepathy's specific model than Matrix, but to be honest I haven't really thought through (or discussed with the rest of the Matrix team) how best to solve our problem. Just to clarify the problem we're looking at solving: * We already have a one true location for a user's conversations, contacts, presence, transferred files, notification settings, search indexes etc: it's their Matrix homeserver, which currently sits in a datacenter somewhere. * However, accessing that server from a multiple different client apps on the same device (mobile or desktop) could start to get a bit gnarly. It's not a problem we have today, as in general people pick a single client (e.g. Riot or nheko or Quaternion or whatever) and stick with it. However, if Matrix was being used as a general communications function for an OS, we can see lots of different apps wanting to dip in to quickly send/receive messages, calls, handle Matrix push notifs etc. * So, the immediate options that spring to my mind are: 1. Each app independently acts as its own client to the server; either speaking the Matrix client-server protocol directly or by using one of the various Matrix client SDKs for the language of choice. This has the advantage of being dead easy (it's how it works already today), but the disadvantages of potentially redundant/duplicate data being synced to each client app over the network; potentially redundant processing (which can be quite complicated - e.g. e2e crypto); and redundant caching of client state (e.g. local copies of logs, e2e keys, etc). 2. We run a homeserver on the local device. This is the holy grail of Matrix dev; evolving servers to run clientside as well as serverside and effectively act as a hybrid p2p/client-server model. We seriously considered leaping ahead to this when we started writing our new homeserver implementation (Dendrite) but instead chose to nail the client-server model first rather than get ahead of ourselves. As such, it's at least a year away from happening. 3. We run a matrix client as a daemon which handles the tasks of e2e crypto, maintaining local conversation cache, etc. However, this would need to expose *some* kind of API through to other apps on the device. In turn, it could make app writers lives much simpler as they don't need to worry about e2e or other 'hard' stuff. It could potentially even handle WebRTC stuff (assuming the client app handed the daemon a window handle of some kind where it should be rendering video). The superficial similarity with the Telepathy architecture made me think of D-Bus as a possible way of doing this, but I really think the similarity is fairly superficial. With this in mind, further comments lie beneath: On 05/09/2017 17:00, Robert McQueen wrote: tl;dr - don't write multi-protocol messengers or gateways unless you have a hugely compelling reason, I did it for 10 years and all I got was this lousy t-shirt ;) I'm not proposing a multi-protocol messenger here; just a way of getting at Matrix efficiently from a variety of different client apps. (Other protocols could conceivably sit behind the same API with some kind of shim to make them look like Matrix, but that's not what we're focused on here at all). In terms of gateways: Matrix does have the concept of bridges, which operate strictly serverside. They act as gateways from Matrix to IRC, Slack, Gitter, Telegram, XMPP, etc. Our hugely compelling reason is that it's a major reason people use Matrix: to defragment communities (bridging them back together into a single Matrix room), and to act as a single UI for accessing a long tail of chatrooms that otherwise folks can't be bothered to run dedicated clients for. One specific instance is IRC bridges, where Matrix effectively just ends up acting as a big decentralised IRC bouncer; sort-of like a decentralised FOSS alternative to IRCCloud. For instance, right now we have around 20K active connections from the matrix.org IRC bridge deployments into ~10 different networks - this feels like a relatively substantial amount of the world's IRC traffic. This feels like a hugely compelling reason to me ;) On 25/08/17 17:43, Matthew Hodgson wrote: Personally, I would really like to have a local comms API abstraction, similar to the one that telepathy provided, but able to support modern protocols - i.e. some daemon which exposes a simple API for multiple apps to leverage when they want to send/receive messages/calls/etc. As I mentioned earlier, we need it for the Librem 5 phone if nothing else (just as Maemo drove the development of telepathy, iirc). Having, er, done this already, for desktops as well as cellphones, I would really seriously encourage you to... not adopt this architecture. Most of the original goals underlying the Telepathy architecture
Re: Matrix as a replacement for Telepathy
tl;dr - don't write multi-protocol messengers or gateways unless you have a hugely compelling reason, I did it for 10 years and all I got was this lousy t-shirt ;) On 25/08/17 17:43, Matthew Hodgson wrote: > Personally, I would really like to have a local comms API abstraction, > similar to the one that telepathy provided, but able to support modern > protocols - i.e. some daemon which exposes a simple API for multiple > apps to leverage when they want to send/receive messages/calls/etc. As > I mentioned earlier, we need it for the Librem 5 phone if nothing else > (just as Maemo drove the development of telepathy, iirc). Having, er, done this already, for desktops as well as cellphones, I would really seriously encourage you to... not adopt this architecture. Most of the original goals underlying the Telepathy architecture turned out to be false. You can't actually/realistically unload the UI of the phone and have it be sufficiently responsive/reliable for things like emergency calls, and you can't (sensibly) implement reliable local logging of messages after you've split the state of whether messages have been received, stored and shown into three processes, and you can't efficiently implement a contact list that aggregates presence and other metadata for contacts unless you have all of the data in process, or copy it round repeatedly (I can only apologise for libfolks). You lose a huge amount by not being able to have your protocol code in the same process as the UI, unless you write an API which basically _is_ your protocol, or an API which is the UI, but the bigger the gap between the two, the more developers fall into that pit and don't get any UI or protocol work done. :) Essentially, adding the D-Bus API to _entirely_ indirect the protocol was, in the end, what made Telepathy so slow, expensive and frustrating to develop, and discouraged any new contributions. As you've rightly pointed out elsewhere in the thread, there is a _lot_ of protocol functionality that appeared even in XMPP at the time, as well as other protocols since, which Telepathy never gained - part of the problem is that there are now a long list of components from spec, logger, client lib, UI, backend, etc that must all be developed and tested together to add one vertical feature (eg - message read receipts). Doing it over again, I'd just make "GNOME Chat" or whatever based on a UI process which could optionally unload/hide it's UI. Then you have single place on the system to do the common stuff like logging, contact aggregation, protocol configuration, managing presence, etc. If you _need_ to export API to integrate to the destkop, you can just implement and export that. But that's really not all that different to Pidgin/libpurple any more, maybe with a nicer GNOME-y UI - or a Matrix-only G* client which implemented everything you needed and had a few touch points. The only thing you lose vs current Telepathy in this scenario is the ostensible security benefits of having your protocols able to be sandboxed off into neat little walled gardens, although Telepathy was in theory architected this way I'm not entirely sure who outside of Nokia/Maemo managed to take advantage of this - possibly SELinux on Fedora/RH? However: with modern protocols and encryption approaches (just look at Telepathy's chequered history with OTR) this falls down _really_ quickly when you need to do things like logging that must be either trusted or not to access/store encrypted messages, potentially a centralised key store, S/ZRTP where the media streaming code needs the key anyway, etc etc - so in a sense I think some of the IM protocols are too "high touch" to be segmented away like that - and then the security is comeing at a high cost of functionality. But in your "Matrix megadaemon" scenario, where you've added a huge complexity/ABI/IPC cost to changing UI <- IPC -> daemon, on top of the existing cost of gateway <- protocol -> client, so you've still got all of these downsides, but none of the upside. > Neither Matrix nor libpurple provides this API out of the box currently. When I started IM client development in whenever it was - 2000 maybe - the hot new thing in Gaim (now Pidgin) was the "core/UI split" where by adding _magic IPC_ to Pidgin, a daemon would appear with all the gnarly protocol/core/etc logic and then a plethora of UIs would arrive on top of it. My recollection is that even without the IPC (which I think didn't get past a "send this message to someone" remote), the effort of cleaning up the internal interfaces to make this even remotely possible burnt out the lead developer at the time, although this did incidentally make libpurple a possibility. Before starting Telepathy we also looked again at this, with "ok, now we have D-Bus, can we just complete that rather than starting our own spec?" and the answer was pretty clearly no, because there is a lot of UI which is dependent on code in the protocol backends. With the benefit
Re: Matrix as a replacement for Telepathy
On 26/08/2017 14:56, Mathieu Bridon wrote: On Fri, 2017-08-25 at 19:13 +0100, Matthew Hodgson wrote: 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. Why bother with a Matrix server at all? Couldn't that local daemon effectively be the Matrix server? At the moment Matrix servers are discovered by DNS and effectively act like any old webservice. We're experimenting with the idea of p2p Matrix though, which would instead use a DHT for discovery - at which point yes, this daemon could act as a fully fledged Matrix server. This would take up a lot more resources (network traffic, consensus calculation, storage) than a daemon acting as a headless client however. And it's still debatable as to whether apps would want to talk to this daemon via the Matrix Client/Server HTTP API or via a more telepathy-style API (which could leave the daemon to handle the 'hard' stuff like e2e crypto, storing local history, etc). At which point from the client app's perspective it wouldn't care if it was talking to a headless client daemon, a server, or a different connection manager entirely. (Of course, native Matrix clients could just talk Matrix natively to their preferred server). M -- Matthew Hodgson Matrix.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, 2017-08-25 at 19:13 +0100, Matthew Hodgson wrote: > 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. Why bother with a Matrix server at all? Couldn't that local daemon effectively be the Matrix server? -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Iterative API design (Was: Re: Matrix as a replacement for Telepathy)
On Fri, Aug 25, 2017 at 10:21:07AM -0500, Gary Kramlich wrote: > > Release 3.0? :) > > I know, need more hours in the day :-/ I'll spend some time this > putting together a 3.0 checklist, but it's not going to be pretty.. > > > Seriously, all that nice GObjectification cleanup does make it a nicer > > proposal as a GNOME framework. > > Yeah, unfortunately it's incomplete, and if we release now, we're just > going to have a super long 4.0 cycle too. I'd rather get through 3.0 > get the GObject based API stable and complete and then get into a > normal development cycle of feature releases again. To avoid being stuck for years with non-optimal APIs, what I do in Tepl is to release a new major parallel-installable version every 6 months if needed (and up until now it *was* needed, but it's a recent library). For more details, see the section "Iterative API design and stability guarantees" at: https://developer.gnome.org/tepl/unstable/intro.html Maybe Linux distro packagers don't really like that, but I think what is more important is that in a few years the library is still relevant, with good APIs. If the GObjectification takes several cycles, no problem, the API doesn't need to be perfect all the time, it should be an iterative process, with frequent releases (e.g. every 6 months), to apply the agile methodology. For porting applications to the new versions of the library, I think it's even easier with more frequent API breaks, because if there is a huge list of API breaks all at once, it's more difficult to port an application (a huge commit is necassary just to be able to compile the code again without errors). Basically, if it hurts, do it more often (if it is necessary): https://martinfowler.com/bliki/FrequencyReducesDifficulty.html -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, 2017-08-25 at 19:13 +0100, Matthew Hodgson wrote: > 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). Well, my primary use cases are Lync, which authenticates with my local Kerberos TGT and thus I'd need to be running the server & bridge on my own laptop, and internal IRC where I suppose I could live with running a server *somewhere* in the corporate network. But for the naïve user case, that doesn't really seem like a step forward. Matrix as just one protocol that's supported, sure. But it doesn't seem to fill the gap that Telepathy or libpurple do. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, Aug 25, 2017 at 11:28:34AM -0500, Michael Catanzaro wrote: > I think what's clear right now is that Telepathy has no future and should be > immediately removed from our stack. We should have done that years ago when > maintenance ceased. Maybe Telepathy and Empathy have utility/self-contained classes or functions that would be worthwhile to keep. To ease the implementation of a new protocol, or to have some re-usable building blocks for the GUI. With the library written more as a toolkit, not a framework. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
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? :) 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). smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Thu, Aug 24, 2017 at 3:40 PM, Sriram Ramkrishna <s...@ramkrishna.me> wrote: What do people think about integrating directly with Matrix as a replacement for Telepathy? I think what's clear right now is that Telepathy has no future and should be immediately removed from our stack. We should have done that years ago when maintenance ceased. I don't think we need to discuss what, if anything, should replace it right now. The community consensus seems to be Matrix, and I'm hoping to see a successful GNOME Matrix client in the near future. I know there are multiple efforts at to make one right now. But people are clearly working on libpurple too, and that's fine. We can let it play out and decide in a couple of years if or how we want to bring back desktop integration for chat. In the meantime, as a longtime Empathy user and a recent convert to Polari, the current state of Telepathy integration in gnome-shell is not valuable to me. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, Aug 25, 2017 at 10:55 AM, David Woodhousewrote: > On Fri, 2017-08-25 at 10:21 -0500, Gary Kramlich wrote: >> > It's also a little hard to add the new features that we need, as things >> > stand. I actually ended up backporting a bunch of stuff from 3.x to the >> > 2.x branch a while back, to support everything that Lync needed. I'm >> > kind of resigned to the fact that I might need to do the same, for the >> > protocol I'm working on now. >> >> Dang, well let me know where I can help. > > Thanks. > > I think you've actually already done the most useful thing, which is to > give me commit access and tell me to go ahead and backport the missing > features to 2.x that I needed. That meant that the lack of a 3.0 > release didn't actually prevent me from being able to ship those > features at all. > > Obviously where I'd want to *change* an API rather than adding one, > that approach is more complicated, but we've been able to cope so far. > > At some point I need to reinstate my access now that the repo has moved > to bitbucket, and then I can start submitting patches for review again. We've just been doing the forking model and saving direct commits to the main repo for extreme circumstances. Ie: tagging and other weird stuff. > On the whole, I quite like the idea of switching from Telepathy to > libpurple. Much more than assuming a one-protocol-to-rule-them-all > approach. Me too, but of course I'm biased ;) > -- > dwmw2 Thanks, -- Gary Kramlich ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, 2017-08-25 at 10:21 -0500, Gary Kramlich wrote: > > It's also a little hard to add the new features that we need, as things > > stand. I actually ended up backporting a bunch of stuff from 3.x to the > > 2.x branch a while back, to support everything that Lync needed. I'm > > kind of resigned to the fact that I might need to do the same, for the > > protocol I'm working on now. > > Dang, well let me know where I can help. Thanks. I think you've actually already done the most useful thing, which is to give me commit access and tell me to go ahead and backport the missing features to 2.x that I needed. That meant that the lack of a 3.0 release didn't actually prevent me from being able to ship those features at all. Obviously where I'd want to *change* an API rather than adding one, that approach is more complicated, but we've been able to cope so far. At some point I need to reinstate my access now that the repo has moved to bitbucket, and then I can start submitting patches for review again. On the whole, I quite like the idea of switching from Telepathy to libpurple. Much more than assuming a one-protocol-to-rule-them-all approach. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, Aug 25, 2017 at 5:13 PM, Tomasz Torczwrote: > It didn't save XMPP, why would this design results in different fate with > Matrix? https://matrix.org/docs/guides/faq.html#what-is-the-difference-between-matrix-and-xmpp -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, Aug 25, 2017 at 03:19:34PM +0300, Adrian Perez de Castro wrote: > While in many respects I like a lot some of the ideas behind Telepahy, and for > example the seamless integration of third-party IM providers in the N900/N9 > was outstanding, there is one major drawback: Making all CMs fit into the > common set of features of all the supported ends up providing a suboptimal > user experience (sometimes vastly inferior). This is one of the reasons why > Empathy was always very mediocre at supporting XMPP and I for many things I > ended up finding myself using Gajim when I was an avid XMPP user. > > On the other hand, by adopting Matrix we have the chance of providing an > exceptional native UX at a potentially much smaller development cost by > focusing on a single protocol [1] — and Matrix itself connecting to > third-party services, instead of trying to solve the fragmentation in the > client-side with subpar solutions. That's kinda ironic, as XMPP was Matrix of its time. There was connectivity to other (proprietary) IM networks through server-side “transports”. Client implementing XMPP only was able to chat with ICQ, GG, MSN, IRC and others – via transports. It didn't save XMPP, why would this design results in different fate with Matrix? -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, Aug 25, 2017 at 10:13 AM, David Woodhousewrote: > On Fri, 2017-08-25 at 09:51 -0500, Gary Kramlich wrote: >> > >> > On Fri, Aug 25, 2017 at 3:59 PM, David Woodhouse wrote: >> > > >> > > On Fri, 2017-08-25 at 15:34 +0200, Alexandre Franke wrote: >> > > > >> > > > If someone cares enough to implement support for a protocol in >> > > > Telepathy, they could probably implement support for the protocol >> > > > elsewhere too. >> > > But where is "elsewhere"? If not libpurple, where *should* I be adding >> > > support for my new toy protocol for example? If you've just taken your >> > > ball and gone home... >> > >> > Well why not libpurple? >> >> As the current lead developer of Pidgin, and thus libpurple, I would >> love to see more people using it. if there's something we can do to >> make Pidgin/libpurple a stronger contender in this race, please let me >> know. > > Release 3.0? :) I know, need more hours in the day :-/ I'll spend some time this putting together a 3.0 checklist, but it's not going to be pretty.. > Seriously, all that nice GObjectification cleanup does make it a nicer > proposal as a GNOME framework. Yeah, unfortunately it's incomplete, and if we release now, we're just going to have a super long 4.0 cycle too. I'd rather get through 3.0 get the GObject based API stable and complete and then get into a normal development cycle of feature releases again. > It's also a little hard to add the new features that we need, as things > stand. I actually ended up backporting a bunch of stuff from 3.x to the > 2.x branch a while back, to support everything that Lync needed. I'm > kind of resigned to the fact that I might need to do the same, for the > protocol I'm working on now. Dang, well let me know where I can help. > But overall, I think libpurple does a fairly good job, even if it needs > a little updating to handle the needs of some new protocols. Thanks! >> Your critiques about needing updates for newer protocols are certainly >> valid, and we're slowly marching towards them as we're trying to >> modernize our codebase. That said if anyone would like to discuss >> them in more detail, I'd love to hear it (off list naturally). > > For my part I haven't quite got there yet. I'm filling in the parts of > the protocol support that libpurple *can* represent, before I turn to > the bits I actually want to extend libpurple for. Understood. > Top of my list will be persistent messages, read receipts and multi-way > V/V calls though. And I've already been asking on the devel list about > why Pidgin has no way to display presence status or full names for an > "unknown" person who sends me an IM, even though my prpl has it and > could tell you. Noted. Thanks, -- Gary Kramlich ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, 2017-08-25 at 09:51 -0500, Gary Kramlich wrote: > > > > On Fri, Aug 25, 2017 at 3:59 PM, David Woodhouse wrote: > > > > > > On Fri, 2017-08-25 at 15:34 +0200, Alexandre Franke wrote: > > > > > > > > If someone cares enough to implement support for a protocol in > > > > Telepathy, they could probably implement support for the protocol > > > > elsewhere too. > > > But where is "elsewhere"? If not libpurple, where *should* I be adding > > > support for my new toy protocol for example? If you've just taken your > > > ball and gone home... > > > > Well why not libpurple? > > As the current lead developer of Pidgin, and thus libpurple, I would > love to see more people using it. if there's something we can do to > make Pidgin/libpurple a stronger contender in this race, please let me > know. Release 3.0? :) Seriously, all that nice GObjectification cleanup does make it a nicer proposal as a GNOME framework. It's also a little hard to add the new features that we need, as things stand. I actually ended up backporting a bunch of stuff from 3.x to the 2.x branch a while back, to support everything that Lync needed. I'm kind of resigned to the fact that I might need to do the same, for the protocol I'm working on now. But overall, I think libpurple does a fairly good job, even if it needs a little updating to handle the needs of some new protocols. > Your critiques about needing updates for newer protocols are certainly > valid, and we're slowly marching towards them as we're trying to > modernize our codebase. That said if anyone would like to discuss > them in more detail, I'd love to hear it (off list naturally). For my part I haven't quite got there yet. I'm filling in the parts of the protocol support that libpurple *can* represent, before I turn to the bits I actually want to extend libpurple for. Top of my list will be persistent messages, read receipts and multi-way V/V calls though. And I've already been asking on the devel list about why Pidgin has no way to display presence status or full names for an "unknown" person who sends me an IM, even though my prpl has it and could tell you. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
> On Fri, Aug 25, 2017 at 3:59 PM, David Woodhousewrote: >> On Fri, 2017-08-25 at 15:34 +0200, Alexandre Franke wrote: >>> If someone cares enough to implement support for a protocol in >>> Telepathy, they could probably implement support for the protocol >>> elsewhere too. >> >> But where is "elsewhere"? If not libpurple, where *should* I be adding >> support for my new toy protocol for example? If you've just taken your >> ball and gone home... > > Well why not libpurple? As the current lead developer of Pidgin, and thus libpurple, I would love to see more people using it. if there's something we can do to make Pidgin/libpurple a stronger contender in this race, please let me know. Your critiques about needing updates for newer protocols are certainly valid, and we're slowly marching towards them as we're trying to modernize our codebase. That said if anyone would like to discuss them in more detail, I'd love to hear it (off list naturally). > -- > Alexandre Franke > GNOME Hacker & Foundation Director Thanks, -- Gary Kramlich ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, Aug 25, 2017 at 3:59 PM, David Woodhousewrote: > On Fri, 2017-08-25 at 15:34 +0200, Alexandre Franke wrote: >> If someone cares enough to implement support for a protocol in >> Telepathy, they could probably implement support for the protocol >> elsewhere too. > > But where is "elsewhere"? If not libpurple, where *should* I be adding > support for my new toy protocol for example? If you've just taken your > ball and gone home... Well why not libpurple? -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, 2017-08-25 at 15:34 +0200, Alexandre Franke wrote: > On Fri, Aug 25, 2017 at 2:05 PM, David Woodhousewrote: > > But isn't that the *point*? We have a framework with plugins for all > > manner of different protocols, instead of a mess of separate protocol- > > specific clients each of which can handle only *one*. > > When the choice is given to me between sticking to an abstraction that > tries but doesn’t manage to grasp the quirks of several protocols, or > switching to a protocol specific API and embrace it to make sure it is > correctly and fully supported, I pick the latter. Even if I have to do > it twice or more. I don’t think the *point* should be to support > several protocols badly. That's very true, and I don't think you're wrong to want a Matrix- specific UI which doesn't attempt to use Telepathy at all. I'm just nitpicking that this isn't a "replacement for Telepathy"; it's rightly ditching Telepathy and just doing your own protocol-specific thing. It's slightly suboptimal for *me* because I'm working on protocol support for Yet Another IM Protocol, as well as occasionally still prodding at the siplcs Lync support, and really don't want to live in a world where each protocol needs to put together its *own* GUI to support it specifically. Right now I'm building my toy as a Pidgin/libpurple plugin but not because I particularly like Pidgin; I think it's fairer to say that I just hate libpurple less than I hate everything *else*. It also has the impedance mismatches and doesn't support some of the things I need like persistent editable messages, read receipts, multi-way V/V calls with indication of who's speaking at any given moment, etc... but it *could* be added... > I also don’t think we should aim at supporting all the protocols that > exist. I don’t think a single client can map to the features of all of > them. Just because it's been done badly/incompletely that doesn't mean it's impossible. > If someone cares enough to implement support for a protocol in > Telepathy, they could probably implement support for the protocol > elsewhere too. But where is "elsewhere"? If not libpurple, where *should* I be adding support for my new toy protocol for example? If you've just taken your ball and gone home... smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On 25/08/2017 14:10, David Woodhouse wrote: On Fri, 2017-08-25 at 14:00 +0100, Matthew Hodgson wrote: From memory, the sort of modern features which Matrix has which the API doesn't handle include: * Infinite scrollback serverside history * Synced history across multiple devices * Server side search * Server side notification settings * Read receipts * Read-up-to markers * Multiway voip * Promoting 1:1s to group chats and vice versa * Native end-to-end encryption (verifying keys, devices, sharing keys, etc) * Encrypted file transfers * Redacted msgs And upcoming shortly: * Reactions / upvotes / downvotes * Editable msgs * Pinned messages * Threading Matrix isn't the only protocol that supports many of those. I'm no fan of Telepathy, certainly — the complete lack of error reporting was what caused me to ditch it and stick with Pidgin for corporate Lync users. When users are completely unaware that they aren't reachable on IM, or why, that's a total UX fail. But I still think we're better off with a *generic* framework, even if we have to drag it into the 21st century, than tying ourselves into a single protocol. You do have to consider that Matrix is intended as a generic protocol, though. The reason it's called Matrix is because it tries to matrix together as many existing silos as possible - but doing the bridging serverside on decentralised bridges. The best way to sum it up is https://twitter.com/matrixdotorg/status/841424770025545730. That said, I totally agree that such a telepathy replacement should also have the option of supporting other protocols natively rather than via Matrix bridges. But it might make sense to take inspiration for the API to be similar to Matrix's (given it's been built for the whole purpose of abstracting multiple protocols, whether that abstraction is done serverside or clientside). Of course if you want to go and make a lovely shiny UI for your single protocol, nobody should dissuade you from that. But to talk about it as a "replacement for Telepathy" doesn't make sense to me. -- Matthew Hodgson Matrix.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, Aug 25, 2017 at 2:05 PM, David Woodhousewrote: > But isn't that the *point*? We have a framework with plugins for all > manner of different protocols, instead of a mess of separate protocol- > specific clients each of which can handle only *one*. When the choice is given to me between sticking to an abstraction that tries but doesn’t manage to grasp the quirks of several protocols, or switching to a protocol specific API and embrace it to make sure it is correctly and fully supported, I pick the latter. Even if I have to do it twice or more. I don’t think the *point* should be to support several protocols badly. I also don’t think we should aim at supporting all the protocols that exist. I don’t think a single client can map to the features of all of them. If someone cares enough to implement support for a protocol in Telepathy, they could probably implement support for the protocol elsewhere too. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, 2017-08-25 at 13:56 +0200, Alexandre Franke wrote: > On Fri, Aug 25, 2017 at 1:46 PM, Felipe Borges wrote: > > > > All in all, if desirable, Matrix and GNU Ring could be connection > > managers in Telepathy instead of standalone bits. > > > > Specific clients could be created backed by Telepathy, e.g. no need to > > rely on Empathy. > > One of the main points of Sri’s proposal is to get rid of Telepathy. > Its architecture is a burden and e.g. Polari has problems because of > the extra layers that wouldn’t exist if it talked to IRC directly. But isn't that the *point*? We have a framework with plugins for all manner of different protocols, instead of a mess of separate protocol- specific clients each of which can handle only *one*. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, 2017-08-25 at 14:00 +0100, Matthew Hodgson wrote: > From memory, the sort of modern features which Matrix has which the API > doesn't handle include: > > * Infinite scrollback serverside history > * Synced history across multiple devices > * Server side search > * Server side notification settings > * Read receipts > * Read-up-to markers > * Multiway voip > * Promoting 1:1s to group chats and vice versa > * Native end-to-end encryption (verifying keys, devices, sharing keys, etc) > * Encrypted file transfers > * Redacted msgs > > And upcoming shortly: > * Reactions / upvotes / downvotes > * Editable msgs > * Pinned messages > * Threading Matrix isn't the only protocol that supports many of those. I'm no fan of Telepathy, certainly — the complete lack of error reporting was what caused me to ditch it and stick with Pidgin for corporate Lync users. When users are completely unaware that they aren't reachable on IM, or why, that's a total UX fail. But I still think we're better off with a *generic* framework, even if we have to drag it into the 21st century, than tying ourselves into a single protocol. Of course if you want to go and make a lovely shiny UI for your single protocol, nobody should dissuade you from that. But to talk about it as a "replacement for Telepathy" doesn't make sense to me. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
-- Matthew Hodgson Matrix.org > On 25 Aug 2017, at 12:46, Felipe Borgeswrote: > >> On Fri, Aug 25, 2017 at 12:15 AM, Alejandro HC wrote: >> A comment as a user. Since Empathy ceased to be maintained, there has been >> little concern for the communication system that is available in gnome >> focused to end user (gnome-polari is targeted to IRC which is mostly used by >> developer communities). >> >> Matrix is great, but I feel it points to the same, so why not support GNU >> Ring in GNOME ... Ring is a project that aims to be a free replacement for >> Skype, in addition already has a good integration in gnome and it's easy to >> use, offering its own communication protocol it offers support for SIP. > > Telepathy was designed as a framework which could have various > "Connection Managers" (in the telepathy terminology). A Connection > Manager is responsible of doing the actual communication with a given > server through a given protocol. Telepathy has connection managers for > XMPP, SIP, IRC, etc... see [0]. For instance, Polari uses Telepathy > for the IRC protocol. Folks have looked at building a telepathy connection manager for Matrix in the past (starting with https://github.com/gergelypolonkai/matrix-glib-sdk and working outwards), but rapidly hit major impedance mismatches with telepathy's API which sadly dates back to a simpler age of IRCv2 and 1st generation IM apps like ICQ or MSN. From memory, the sort of modern features which Matrix has which the API doesn't handle include: * Infinite scrollback serverside history * Synced history across multiple devices * Server side search * Server side notification settings * Read receipts * Read-up-to markers * Multiway voip * Promoting 1:1s to group chats and vice versa * Native end-to-end encryption (verifying keys, devices, sharing keys, etc) * Encrypted file transfers * Redacted msgs And upcoming shortly: * Reactions / upvotes / downvotes * Editable msgs * Pinned messages * Threading So, the choices are either to build a new version of telepathy with that sort of featureset, or build something new which exposes Matrix's API via Dbus or similar. One could then use local or remote bridges to other protocols (or follow the "connection mgr" pattern to implement them locally, but given that would barely be using Matrix at all it's not really our focus). M > > All in all, if desirable, Matrix and GNU Ring could be connection > managers in Telepathy instead of standalone bits. > > Specific clients could be created backed by Telepathy, e.g. no need to > rely on Empathy. > > [0] https://telepathy.freedesktop.org/components/ > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
Hi all, I wholeheartedly support (+1!) scraping Telepathy and going full-Matrix. On Fri, 25 Aug 2017 13:56:24 +0200, Alexandre Frankewrote: > On Fri, Aug 25, 2017 at 1:46 PM, Felipe Borges wrote: > > All in all, if desirable, Matrix and GNU Ring could be connection > > managers in Telepathy instead of standalone bits. > > > > Specific clients could be created backed by Telepathy, e.g. no need to > > rely on Empathy. > > One of the main points of Sri’s proposal is to get rid of Telepathy. > Its architecture is a burden and e.g. Polari has problems because of > the extra layers that wouldn’t exist if it talked to IRC directly. While in many respects I like a lot some of the ideas behind Telepahy, and for example the seamless integration of third-party IM providers in the N900/N9 was outstanding, there is one major drawback: Making all CMs fit into the common set of features of all the supported ends up providing a suboptimal user experience (sometimes vastly inferior). This is one of the reasons why Empathy was always very mediocre at supporting XMPP and I for many things I ended up finding myself using Gajim when I was an avid XMPP user. On the other hand, by adopting Matrix we have the chance of providing an exceptional native UX at a potentially much smaller development cost by focusing on a single protocol [1] — and Matrix itself connecting to third-party services, instead of trying to solve the fragmentation in the client-side with subpar solutions. Cheers, -- Adrián “Two Cents” Pérez [1] Like Polari is strivin to do. pgpT3qi7o7x2g.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
Matrix is about much more than IRC-style communication, although it's a common misunderstanding given most of the popular use of Matrix today happens to be as a decentralised IRC/Slack/Gitter/Telegram alternative. We have Skype-style voice and video calls too, as well as conference calls (and as of two days ago, integration with other conferencing platforms like Jitsi). For instance, we've just teamed up with the Purism guys to deliver a VoIP/messaging app for their new Librem 5 FLOSS smartphone: https://matrix.org/blog/2017/08/24/the-librem-5-from-purism-a-matrix-native-smartphone/. I'm obviously biased, but I think that using Matrix as an alternative to Telepathy would be a great idea. One of the proposed pieces of work for the Purism deal in fact would be to run a background Matrix client on the phone which can receive Matrix push notifications, inbound messages & calls etc, and expose them via DBUS or similar for the rest of the OS to use. Thus applications could either talk HTTP direct to their preferred Matrix server, or use a Matrix-over-DBUS style API to share the same daemon across all apps. This could also be super-useful for E2E crypto, as the heavy lifting crypto work could be done by a shared daemon, and expose a simple plaintext API through to the client apps on the machine itself (assuming you trusted the host sufficiently). This work is currently a stretch goal for the Purism campaign though if they significantly overshoot their funding target, so if the wider GNOME or Matrix or Linux community was interested in pursuing this sooner than later it would only be a Good Thing. thanks, Matthew On 24/08/2017 23:15, Alejandro HC wrote: A comment as a user. Since Empathy ceased to be maintained, there has been little concern for the communication system that is available in gnome focused to end user (gnome-polari is targeted to IRC which is mostly used by developer communities). Matrix is great, but I feel it points to the same, so why not support GNU Ring in GNOME ... Ring is a project that aims to be a free replacement for Skype, in addition already has a good integration in gnome and it's easy to use, offering its own communication protocol it offers support for SIP. 2017-08-24 17:40 GMT-03:00 Sriram Ramkrishna <s...@ramkrishna.me <mailto:s...@ramkrishna.me>>: I thought I would put it out there after some discussion to make sure it isn't a completely crazy idea. What do people think about integrating directly with Matrix as a replacement for Telepathy? This would mean that we can focus on chat, video-conferencing, and anything else through Matrix. We'd have to abandon clients like empathy (or modify). For IRC we would use our own library or use matrix's bridge. This way, we can push this support to an upstream that cares and is culturally compatible with us. Matrix of course gets a boost from a major group relying on them and providing alternative clients and a superior (hopefully) user experience. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org <mailto:desktop-devel-list@gnome.org> https://mail.gnome.org/mailman/listinfo/desktop-devel-list <https://mail.gnome.org/mailman/listinfo/desktop-devel-list> -- *Hugo* ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Matthew Hodgson Matrix.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, Aug 25, 2017 at 1:46 PM, Felipe Borgeswrote: > All in all, if desirable, Matrix and GNU Ring could be connection > managers in Telepathy instead of standalone bits. > > Specific clients could be created backed by Telepathy, e.g. no need to > rely on Empathy. One of the main points of Sri’s proposal is to get rid of Telepathy. Its architecture is a burden and e.g. Polari has problems because of the extra layers that wouldn’t exist if it talked to IRC directly. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, Aug 25, 2017 at 12:15 AM, Alejandro HCwrote: > A comment as a user. Since Empathy ceased to be maintained, there has been > little concern for the communication system that is available in gnome > focused to end user (gnome-polari is targeted to IRC which is mostly used by > developer communities). > > Matrix is great, but I feel it points to the same, so why not support GNU > Ring in GNOME ... Ring is a project that aims to be a free replacement for > Skype, in addition already has a good integration in gnome and it's easy to > use, offering its own communication protocol it offers support for SIP. Telepathy was designed as a framework which could have various "Connection Managers" (in the telepathy terminology). A Connection Manager is responsible of doing the actual communication with a given server through a given protocol. Telepathy has connection managers for XMPP, SIP, IRC, etc... see [0]. For instance, Polari uses Telepathy for the IRC protocol. All in all, if desirable, Matrix and GNU Ring could be connection managers in Telepathy instead of standalone bits. Specific clients could be created backed by Telepathy, e.g. no need to rely on Empathy. [0] https://telepathy.freedesktop.org/components/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
A comment as a user. Since Empathy ceased to be maintained, there has been little concern for the communication system that is available in gnome focused to end user (gnome-polari is targeted to IRC which is mostly used by developer communities). Matrix is great, but I feel it points to the same, so why not support GNU Ring in GNOME ... Ring is a project that aims to be a free replacement for Skype, in addition already has a good integration in gnome and it's easy to use, offering its own communication protocol it offers support for SIP. 2017-08-24 17:40 GMT-03:00 Sriram Ramkrishna <s...@ramkrishna.me>: > I thought I would put it out there after some discussion to make sure it > isn't a completely crazy idea. > > What do people think about integrating directly with Matrix as a > replacement for Telepathy? This would mean that we can focus on chat, > video-conferencing, and anything else through Matrix. We'd have to abandon > clients like empathy (or modify). For IRC we would use our own library or > use matrix's bridge. > > This way, we can push this support to an upstream that cares and is > culturally compatible with us. Matrix of course gets a boost from a major > group relying on them and providing alternative clients and a superior > (hopefully) user experience. > > sri > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- *Hugo* ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Thu, Aug 24, 2017 at 10:40 PM, Sriram Ramkrishna <s...@ramkrishna.me> wrote: > What do people think about integrating directly with Matrix as a replacement > for Telepathy? Yes please. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Matrix as a replacement for Telepathy
I thought I would put it out there after some discussion to make sure it isn't a completely crazy idea. What do people think about integrating directly with Matrix as a replacement for Telepathy? This would mean that we can focus on chat, video-conferencing, and anything else through Matrix. We'd have to abandon clients like empathy (or modify). For IRC we would use our own library or use matrix's bridge. This way, we can push this support to an upstream that cares and is culturally compatible with us. Matrix of course gets a boost from a major group relying on them and providing alternative clients and a superior (hopefully) user experience. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list