Re: The chat situation
The incompatibility in capabilities between IRC, Matrix, and Telegram feels like it makes smooth communication between all three all but impossible. Maybe I'm wrong about this--hopefully I am! Because I think that if we're going to stay with Matrix, we need to somehow improve the UX in directions that attract all the people who currently use either Telegram or IRC with the goal of deprecating both. Because if Matrix can't be better than the two things it was intended to replace, then it's not a success, right? If our Matrix instance is sponsored such that requesting support, maintenance, or development resources costs somebody else time and money, that seems problematic for the prospect of the issues under discussion being ironed out. Hopefully there are at least some things we can take care of on our side to improve the situation. Nate
Re: The KDEPIM / Akonadi situation
It's quite possible to take a large and technically flawed project and fix the technical flaws over time. Arguably this has happened in Baloo over the past year or two, and I see far fewer user complaints about it than I did in the past. It's working almost perfectly for me. I don't know enough about Akonadi's technical undrpinnings to say whether this will be possible there, or whether it's just an impossible undertaking though. However I think there is a bigger challenge that just the technical issues. My interactions in bug reports have been quite negative, I have to say, and I don't feel like the developer culture is very welcoming right now. This probably has to change or else the project will fail to attract the kind of manpower needed to achieve a state of greater reliability, which I think needs to be the top priority in business-ish software. I'm currently using Thunderbird as my email client and it is boringly reliable. Everything works 100%, 100% of the time. There is no drama whatsoever, and no maintenance required. That's the goal. Nate
Re: The chat situation
XYQuadrat - 11.06.20, 16:15:04 CEST: > First off, let me say that I personally have been increasingly > satisfied with Matrix and am of the opinion that once an alternative > homeserver implementation (Dendrite or conduit.rs come to mind, both > of them have top-notch performance) is ready for production, it will > be the optimal solution for KDE. Additionally, as a young developer > (< 20 years old), I very much appreciate how similar Matrix is to > other chat services and would likely be less active if I had to > participate via IRC. > > What I am asking myself right now is how to lead this discussion into > the most productive way possible. I have gathered from the current > mails in this thread that there is a wide variety of opinions, > preferences and approaches to this problem. There has already been a > community-wide poll > (https://sessellift.wordpress.com/2017/09/05/results-of-the-requireme > nts-survey-for-a-kde-wide-chat-solution/) back in 2017 - are the > requirements based on this survey still accurate? Additionally, how > can we most efficiently reach a decision on what to do? I suspect > that simply talking about the pros and cons of Matrix and IRC will > not get us anywhere. I am not really opposed to Matrix… I just didn't use it so far, cause I… meanwhile hate Google Recaptcha with a passion. As far as I read it is a privacy nightmare in that if it can it gather all kinds of data from the client browser, it provides free machine learning data for Google… and it just does not fit in how I think the internet should work. I understand why it is so often used… however I have also seen alternatives, like for example on the register page of dismail.de – but there is also some open source self host-able alternative I have come across once. I do not recall the name currently. I am also pretty sure I did not need to answer a Recaptcha for registering with disroot.org Also for chat I do prefer to use a real desktop client. No website. And also no website in a desktop client, although I put up with Rocket.Chat electron client so far even if it mainly is just that as far as I understand. Mobile phone app would be optional for me but I bet it is important for many people. Anyway, yeah… good would be to get an idea how to continue? Is there any short-term things that can be done about the Matrix situation so that the currently felt pain can be relieved a bit? This would give more time to focus on a longer term approach. I still recall it, it was quite a discussion about chat systems before Matrix was chosen and I do believe there have been good reasons for the choice. -- Martin
Re: The chat situation
Ilmari Lauhakangas - 11.06.20, 15:18:33 CEST: > Christian Loosli kirjoitti 11.6.2020 klo 15.25: > > And while IRC is improving (and you are very welcome to participate > > e.g. in #ircv3 or #freenode-dev on freenode) two of the main pain > > points people mention (lack of an endless scrollback / offline > > history, uploading media directly) are unlikely to fully happen on > > freenode / IRC, due to both technical and privacy / legal reasons. > > There is very likely to be (offline) backlog, but it will be > > time-limited due to the above constraints. Not having these > > constraints means someone else (neither freenode nor probably KDE) > > has both the storage and the legal willingness to store that data, > > with all implications this brings (DSVGO, security and privacy, > > ...) > > These are usually profit oriented companies, and having to rely on > > these brings up some new issues. > > I'm not sure an endless scrollback is a dealbreaker. I've noticed > folks in Telegram talking about cleanup bots that regularly delete > the history due to whatever privacy concerns. But in general, sure, > people want hosting & backups & everything for free and top notch > customer support :) /me looks at a certain 703 MiB large Quasselcore SQLite database and… hides… Really need to check for a script to clean it up at some point. But would like to it clean out public chats and keep private ones for example. For some reasons Quassel IRC still runs quite fast despite this database size. -- Martin
Re: The chat situation
Carl Schwan - 11.06.20, 15:15:36 CEST: > Maybe it is the time to consider other open-source alternatives like > Mattermost or Rocket Chat... GNOME did it, Blender did it, we even > have a Rocket Chat client in KDE now! We do have Rocket.Chat at work and I can say I am quite happy with it. It is not perfect, but good enough, for me at least. Although especially threads are cumbersome UI wise. Sharing images or other files works quite well. I am using the official Electron client still, but there is a KDE/Qt based one, called Ruqola? Never tried it out so far. -- Martin
Re: The KDEPIM / Akonadi situation
Hi Martin, thank you very much for bringing this up. I had a minor rant about the situation on the enterprise list back when I also used KDE apps at work, I'm afraid from what I can see the situation is mostly the same. I ended up with a messed up DB a couple of times that I was only able to solve by simply deleting and re-adding the IMAP account. As a funny bit of irony, I tried to reply to your message earlier, but kmail wouldn't let me because it asked me, with a pop up, to wait for transmission of the message for a couple of minutes. Unfortunately I also don't have any ready-made solution for it, we can't really force people to work on a certain product, and the whole akonadi-stack is probably also not something terribly new-person-friendly. I know that there was an alternative being worked on, but I lost track of that as well. Maybe making it a goal could help, or to have some sort of sprint around it. Or, even though I personally am usually very much against these, some sort of bounty. In any case I think the situation needs improvement and I'm glad you brought it up, so this is mostly in support of the request, because it stayed reply- less for a while. Kind regards, Christian
Re: The chat situation
Hi, First off, let me say that I personally have been increasingly satisfied with Matrix and am of the opinion that once an alternative homeserver implementation (Dendrite or conduit.rs come to mind, both of them have top-notch performance) is ready for production, it will be the optimal solution for KDE. Additionally, as a young developer (< 20 years old), I very much appreciate how similar Matrix is to other chat services and would likely be less active if I had to participate via IRC. What I am asking myself right now is how to lead this discussion into the most productive way possible. I have gathered from the current mails in this thread that there is a wide variety of opinions, preferences and approaches to this problem. There has already been a community-wide poll (https://sessellift.wordpress.com/2017/09/05/results-of-the-requirements-survey-for-a-kde-wide-chat-solution/) back in 2017 - are the requirements based on this survey still accurate? Additionally, how can we most efficiently reach a decision on what to do? I suspect that simply talking about the pros and cons of Matrix and IRC will not get us anywhere. Best wishes, Julian On 11.06.20 01:16, Nate Graham wrote: Carson's email about bridging #kde-devel to Telegram got me thinking: we should have a discussion about the situation we're in regarding chat services in KDE. The current Matrix solution does not seem not optimal to me. I have really tried my best to be a good citizen and use Matrix as much as possible over the last year but I find myself gravitating back towards Telegram because of how much better the overall UX is, especially for fast-moving discussions and those involving images. I haven't found a Matrix client that offers both a half-decent UX and also a reasonable featureset. The service suffers from lag, sometimes severe. Periodically the federation breaks, or the bridge between IRC and Telegram breaks, leading to people's messages silently vanishing. The implementation of the bridge itself impedes discussions between Telegram users and IRC/Matrix users because when a Telegram user replies to a post made by someone on IRC or Matrix, that person person can't see the message being replied to. Overall it just does not feel like a great user experience. This situation really needs to be fixed, somehow. I'm not knowledgeable enough regarding chat software to be able to propose solution, but I don't feel like the status quo is something we should live with. Can we fix Matrix? Or should we migrate to something that offers a better UX? Nate
Re: Discontinuing legacy infrastructure
El dijous, 11 de juny de 2020, a les 11:11:48 CEST, Ben Cooksley va escriure: > Hi all, > > 2) CGit has been discontinued > > The CGit instance previously available at cgit.kde.org has now been > shutdown and is no longer available. All repository browsing should > now take place via Gitlab at https://invent.kde.org/ Could we make cgit.kde.org/* redirect to https://invent.kde.org/ (just the homepage) I guess there's a zillion links to cgit.kde.org out there, and i guess it'd be good that at least they're not left totally dangling. Cheers, Albert
Re: The chat situation
On Thursday, 11 June 2020 14:15:36 BST Carl Schwan wrote: > Same thing with the lag issue. It could be partially resolved if we were > using the kde.org node instead of the matrix.org for the bridging and it was > asked multiple times in this channel by someone else. But this is still not > solved. I wonder if someone in KDE has some control over it. > Hi There is an IRC bridge on :kde.org however some of the channels are being accessed via :kde.org aliases pointing to :matrix.org rooms for legacy reasons. We have requested these get moved over but it appears to require manual work by their admins and nothing seems to have been done recently -- Kenny (Pronouns: he/him)
Re: The chat situation
Hi Carl, Am Donnerstag, 11. Juni 2020, 15:15:36 CEST schrieb Carl Schwan: > The problem with Matrix in KDE is that I'm not even sure someone is actively > working on improving the situation. > > I know the KDE sysadmins are not maintaining it and instead, in case of > problem, people should go to #kde-matrix-support:kde.org. So I tried asking > multiple times about why my matrix account doesn't get any message from the > irc and telegram bridge and never got an answer. So far my experiences in there were okay, but it might depend on various things, such as timezones, day of the week or just being lucky. Our KDE instance is, as far as I am aware, sponsored, so we (KDE, also for follow-up-we) do not only not give them any money, but by using their support sort of "costing them" money. This is an issue we will have with any chat system: either we are willing to maintain our own (which I assume we'd have to with Rocket), so we'd need to check if we have the ressources, both server- and people wise. Or, as we currently do with freenode IRC and Matrix, we outsource that, then we need to see if we trust the entity we outsource to, and if we are happy with their support. > The major reason why we chose Matrix was, because it allowed > communication with people still using IRC and was more user friendly. But > actually to be able to interact with those peoples, a new user should > register their nick on Freenode and using this nick on Matrix by using > some commands that need to be repeated every few weeks. I don't think this > process is very user friendly. Uh, I'm not sure where you got that, but: 1) nickserv registration is _not_ mandatory. IRC on freenode, compared to other solutions, does not force you to register and thus giving an e-mail address (Matrix), phone number (like Telegram) or similar. However, we (freenode) give channel operators the possibility to (temporarily or for good) make the channel only accessible to registered users, which can be used to cut down abuse / spam. However, I haven't seen any of that in recent months, so channels should be fine without this setting. 2) the process should not have to be repeated. You only have to register once, and unless Matrix is doing something silly, you should auto-authenticate on connect. 3) the process itself could be improved, however, we (freenode) on the IRC side can't really do anything more on that end, that would have to come from Matrix (I assume it shouldn't be too hard to have a proper GUI for that) > Maybe it is the time to consider other open-source alternatives like > Mattermost or Rocket Chat... GNOME did it, Blender did it, we even have a > Rocket Chat client in KDE now! I'd have to go back to the requirement collecting and voting process we had in 2017 on why Rocket didn't make it (because it was a candidate), as far as I remember it isn't trivial to maintain (only docker? Something like that) and I am not aware of any company or entity that would sponsor us an instance and take care of it, so if we wanted to switch, we'd need to ensure that our infra is willing and able to set it up and maintain / support it. Kind regards, Christian
Re: The chat situation
Christian Loosli kirjoitti 11.6.2020 klo 15.25: And while IRC is improving (and you are very welcome to participate e.g. in #ircv3 or #freenode-dev on freenode) two of the main pain points people mention (lack of an endless scrollback / offline history, uploading media directly) are unlikely to fully happen on freenode / IRC, due to both technical and privacy / legal reasons. There is very likely to be (offline) backlog, but it will be time-limited due to the above constraints. Not having these constraints means someone else (neither freenode nor probably KDE) has both the storage and the legal willingness to store that data, with all implications this brings (DSVGO, security and privacy, ...) These are usually profit oriented companies, and having to rely on these brings up some new issues. I'm not sure an endless scrollback is a dealbreaker. I've noticed folks in Telegram talking about cleanup bots that regularly delete the history due to whatever privacy concerns. But in general, sure, people want hosting & backups & everything for free and top notch customer support :) Ilmari
Re: The chat situation
The problem with Matrix in KDE is that I'm not even sure someone is actively working on improving the situation. I know the KDE sysadmins are not maintaining it and instead, in case of problem, people should go to #kde-matrix-support:kde.org. So I tried asking multiple times about why my matrix account doesn't get any message from the irc and telegram bridge and never got an answer. Same thing with the lag issue. It could be partially resolved if we were using the kde.org node instead of the matrix.org for the bridging and it was asked multiple times in this channel by someone else. But this is still not solved. I wonder if someone in KDE has some control over it. The major reason why we chose Matrix was, because it allowed communication with people still using IRC and was more user friendly. But actually to be able to interact with those peoples, a new user should register their nick on Freenode and using this nick on Matrix by using some commands that need to be repeated every few weeks. I don't think this process is very user friendly. Maybe it is the time to consider other open-source alternatives like Mattermost or Rocket Chat... GNOME did it, Blender did it, we even have a Rocket Chat client in KDE now! Le jeudi, juin 11, 2020 6:38 AM, Bernie Innocenti a écrit: Doesn't Riot.im support images well enough for your use-case? It's free software, and it's becoming fairly mature lately. The root issue for both Telegram and Matrix seems to be that they're bridging through a legacy platform like IRC. Would it be fair to say that this problem will slowly resolve itself in time, as users leave IRC? I don't mean to troll: I've been on IRC myself for 20+ years, but the protocol has been stagnating and clients requires too much setup for newcomers, particularly when you consider identity, presence and persistence. Other open source projects are migrating to Matrix or Gitter, and soon or later KDE will need to make a decision. On 11/06/2020 09.09, Carl Schwan wrote: Hi, Strong +1 on this. The current situation is far from good. Currently to have a good communication application I need to either use a proprietary platform, use a platform who doesn't support images and for which I need to set up a bouncer on my server or use a platform which lags a lot and which doesn't always relays my messages to the bridges. Carl Le mercredi, juin 10, 2020 11:16 PM, Nate Graham n...@kde.org a écrit: Carson's email about bridging #kde-devel to Telegram got me thinking: we should have a discussion about the situation we're in regarding chat services in KDE. The current Matrix solution does not seem not optimal to me. I have really tried my best to be a good citizen and use Matrix as much as possible over the last year but I find myself gravitating back towards Telegram because of how much better the overall UX is, especially for fast-moving discussions and those involving images. I haven't found a Matrix client that offers both a half-decent UX and also a reasonable featureset. The service suffers from lag, sometimes severe. Periodically the federation breaks, or the bridge between IRC and Telegram breaks, leading to people's messages silently vanishing. The implementation of the bridge itself impedes discussions between Telegram users and IRC/Matrix users because when a Telegram user replies to a post made by someone on IRC or Matrix, that person person can't see the message being replied to. Overall it just does not feel like a great user experience. This situation really needs to be fixed, somehow. I'm not knowledgeable enough regarding chat software to be able to propose solution, but I don't feel like the status quo is something we should live with. Can we fix Matrix? Or should we migrate to something that offers a better UX? Nate -- _ // Bernie Innocenti \X/ https://codewiz.org/ publickey - carl@carlschwan.eu - 0x7F564CB5.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: The chat situation
Hi all, couple of inputs from my side, with both a KDE and a freenode hat on: First of all, I do agree that the situation is not great and could be improved. However, I doubt that "switching to a single product" / "abandon bridging" would really improve the situation. Projects that went that path, e.g. Mozilla, suffered from even more community fragmentation, because some people are not happy with $product for various valid reasons (forced registration, not-open, lack of well integrating or accessible clients etc.) This is something we wanted to avoid back when the discussion came up that did lead to the current situation. Also Matrix, from what I can see, seems to have bridging issues that do not include IRC, so e.g. bridging Telegram and Matrix directly might improve the situation, but not fully solve it. And while IRC is improving (and you are very welcome to participate e.g. in #ircv3 or #freenode-dev on freenode) two of the main pain points people mention (lack of an endless scrollback / offline history, uploading media directly) are unlikely to fully happen on freenode / IRC, due to both technical and privacy / legal reasons. There is very likely to be (offline) backlog, but it will be time-limited due to the above constraints. Not having these constraints means someone else (neither freenode nor probably KDE) has both the storage and the legal willingness to store that data, with all implications this brings (DSVGO, security and privacy, ...) These are usually profit oriented companies, and having to rely on these brings up some new issues. Some of these issues can be solved already though, various well improving bouncer solutions have been mentioned, and exchanging media / displaying it can be solved in the frontend, as some clients already do. It just means relying on an external service, but we already do that in other areas. On the XMPP / messenger end I can't really say much other than the situation being most likely not satisfactory, but as people around me stopped using these protocols and switched to (semi)proprietary solutions, so unfortunately did I. Kind regards, Christian
Re: The chat situation
Bernie Innocenti kirjoitti 11.6.2020 klo 14.02: On 11/06/2020 19.28, Ilmari Lauhakangas wrote: Bernie Innocenti kirjoitti 11.6.2020 klo 9.38: Doesn't Riot.im support images well enough for your use-case? It's free software, and it's becoming fairly mature lately. The root issue for both Telegram and Matrix seems to be that they're bridging through a legacy platform like IRC. Would it be fair to say that this problem will slowly resolve itself in time, as users leave IRC? I don't mean to troll: I've been on IRC myself for 20+ years, but the protocol has been stagnating and clients requires too much setup for newcomers, particularly when you consider identity, presence and persistence. Other open source projects are migrating to Matrix or Gitter, and soon or later KDE will need to make a decision. While progress with the IRC protocol has been slow, I would say freenode is suffering from stagnation the most at the moment. A service like KiwiBNC can act as a shim on top of freenode to bring modernity to everyone, but obviously limits to UX improvements will be hit. Freenode could solve this by moving to an actively-maintained IRCd (or invest a lot in their homegrown one). Maybe a member of the KDE community could go on on #freenode and bring up the issue of stagnation in a civilized manner (like... without saying "give us $FEATURE or else we walk away" :-) I'm sure they're already aware of it, and perhaps they're already working on a plan to address some of our issues, and looking for volunteers who want to help. Well, there is even one KDE/freenode hybrid contributor in our known galaxy :) An alternative would be setting up completely self-hosted IRC infra. This would really open up the possibilities as there are solutions like https://oragono.io/ which comes with an integrated bouncer. A modern IRCd that doesn't look like it was written back in the 80's? WOW. It has all green boxes except for setname: https://ircv3.net/software/servers.html Still... it feels like IRCv3 is still doing too little, too late. The design team needs to share images and short videos. Everyone wants threaded replies, profile pics... So we need to wait for IRCv4, or switch to things like Matrix and Gitter, which are *already* IRCv4 ;-) Yeah, it feels like a "boiling the ocean" type of scenario for sure with the ideal being clients advancing in lockstep with servers on the spec implementation. Threaded replies is a good example as the client-only reply tag has a single implementation: IRCCloud. Image & file sharing I feel could be addressed by self-hosting, but of course it would need client support as well for the upload. For example, there is a file uploader plugin for the KiwiIRC webclient: https://github.com/kiwiirc/plugin-fileuploader Profile pics / avatars as metadata have some implementations (at least IRCCloud). The metadata spec actually got a rewrite already (in draft status currently): https://github.com/ircv3/ircv3-specifications/pull/339 Ilmari
Re: The chat situation
On 11/06/2020 18.32, Martin Steigerwald wrote: I am still using IRC. Last time I tried to register for Matrix it put up some Google Recaptcha and is where I lost my interest already. You might have missed it, but identity.kde.org also uses reCAPTCHA :-) And how else would they keep spammers under control? Other hosted chats ask for your email address or even your phone number... But aside from that, I believe part of the thing is: I am not using *any* chat client from KDE at the moment. Why? There are not up to par with what would be needed: Kopete currently is not even in Debian unstable… and last it was, it wasn't working all that well. And no OMEMO with XMPP either. Also it claims to support many more chat protocols than make sense. KDE Telepathy appears to be abandoned completely. Even Konversation does not seem to receive a lot of attention, or am I missing something? It however still appears to be quite usable. But I am using Quassel IRC anyway… I'm using Quassel too and it's great... if you have your own server! Most users don't. And anyway, running a bouncer or quassel-core adds a layer of complexity on top of an ancient protocol with weak identity and persistence model. Long-time IRC users like you have already paid the cost of learning and setting up this pile of hacks long ago. But we should be conscious that it's highly unreasonable for new users. Also, the Visual Design Group is asking for a chat protocol that can share images and videos. This is not even close to ever happen on IRC in a way that interoperates across clients. This is why I think we should give up on IRC and just migrate to Matrix, Gitter, or maybe Telegram (since it's already being used by the designers and seems to be their preferred choice). Bridging networks might *seem* like it would give everyone their favorite choice, but in practice it results in poor UX and serious communication issues (as Nate already noted). Kaidan.im – I hope it will get there, without OMEMO no option for me. I think this could be one of the next community goals after the currently running 3 years period… fix up the chat software situation in KDE. However for now that won't help. So for now there may be the option to find a suitable combination of *some* chat client, even outside of KDE project, with chat server that satisfies people. I'd keep IRC however until there would be something that could convince all those IRC users to switch over. Thanks, -- _ // Bernie Innocenti \X/ https://codewiz.org/
Re: The chat situation
On donderdag 11 juni 2020 08:20:55 CEST Kevin Ottens wrote: > I've not been a good citizen like you and stuck mostly to IRC so I got a > question out of curiosity (and because I think it'll impact the decision > making). > > Regarding the lags and the breakages, do they happen only to bridged > channels? > Or do they happen also for "pure" Matrix channels as well? > I'm not using matrix either, after some initial trials. When using webchat.kde.org, I find that the "feel" of having a conversation is completely absent, probably because every message takes way too much space. I also don't _want_ to set up encryption to "keep my chats" safe... I've tried to setup a console client, but haven't managed that. Given that the stated reason to move from irc to matrix was to attract new, younger developers who would be scared away by irc, I wonder if anyone has done any statistics on that? . -- https://www.krita.org
Re: The chat situation
On 11/06/2020 19.28, Ilmari Lauhakangas wrote: Bernie Innocenti kirjoitti 11.6.2020 klo 9.38: Doesn't Riot.im support images well enough for your use-case? It's free software, and it's becoming fairly mature lately. The root issue for both Telegram and Matrix seems to be that they're bridging through a legacy platform like IRC. Would it be fair to say that this problem will slowly resolve itself in time, as users leave IRC? I don't mean to troll: I've been on IRC myself for 20+ years, but the protocol has been stagnating and clients requires too much setup for newcomers, particularly when you consider identity, presence and persistence. Other open source projects are migrating to Matrix or Gitter, and soon or later KDE will need to make a decision. While progress with the IRC protocol has been slow, I would say freenode is suffering from stagnation the most at the moment. A service like KiwiBNC can act as a shim on top of freenode to bring modernity to everyone, but obviously limits to UX improvements will be hit. Freenode could solve this by moving to an actively-maintained IRCd (or invest a lot in their homegrown one). Maybe a member of the KDE community could go on on #freenode and bring up the issue of stagnation in a civilized manner (like... without saying "give us $FEATURE or else we walk away" :-) I'm sure they're already aware of it, and perhaps they're already working on a plan to address some of our issues, and looking for volunteers who want to help. An alternative would be setting up completely self-hosted IRC infra. This would really open up the possibilities as there are solutions like https://oragono.io/ which comes with an integrated bouncer. A modern IRCd that doesn't look like it was written back in the 80's? WOW. It has all green boxes except for setname: https://ircv3.net/software/servers.html Still... it feels like IRCv3 is still doing too little, too late. The design team needs to share images and short videos. Everyone wants threaded replies, profile pics... So we need to wait for IRCv4, or switch to things like Matrix and Gitter, which are *already* IRCv4 ;-) -- _ // Bernie Innocenti \X/ https://codewiz.org/
Re: The chat situation
Bernie Innocenti kirjoitti 11.6.2020 klo 9.38: Doesn't Riot.im support images well enough for your use-case? It's free software, and it's becoming fairly mature lately. The root issue for both Telegram and Matrix seems to be that they're bridging through a legacy platform like IRC. Would it be fair to say that this problem will slowly resolve itself in time, as users leave IRC? I don't mean to troll: I've been on IRC myself for 20+ years, but the protocol has been stagnating and clients requires too much setup for newcomers, particularly when you consider identity, presence and persistence. Other open source projects are migrating to Matrix or Gitter, and soon or later KDE will need to make a decision. While progress with the IRC protocol has been slow, I would say freenode is suffering from stagnation the most at the moment. A service like KiwiBNC can act as a shim on top of freenode to bring modernity to everyone, but obviously limits to UX improvements will be hit. Freenode could solve this by moving to an actively-maintained IRCd (or invest a lot in their homegrown one). An alternative would be setting up completely self-hosted IRC infra. This would really open up the possibilities as there are solutions like https://oragono.io/ which comes with an integrated bouncer. Ilmari
The KDEPIM / Akonadi situation
Hi! Another community goal aside from fixing up the chat software situation within KDE could be to either fix Akonadi or replace it by something that works… Plasma and KDE Frameworks got a huge ton better in the last releases. But other parts of the KDE ecosystem appear to be mostly abandoned – like Kopete or KDE Telepathy – or in case they receive continuous development like with KDEPIM/Akonadi that continuous development does not seem to have achieved a stable, reliable and well performing solution for users in the recent years. Quite the contrary, with KDEPIM / Akonadi 20.04 it got worse. Just look at kdepim-users mailing list, on bugs.kde.org or on the internet. Since years many users are quite unhappy with the situation. Quite some abandoned KDEPIM after a lot of frustration with it. And I considered myself to abandon it way more than once as well, currently considering to switch to something else again. I was putting up with all the deficiencies, but recently it became quite unbearable for me as well as the situation for local maildir resources worsened considerably – Debian unstable / testing users are hit by this currently, I wonder why it wasn't reported before: Frustrating to use KMail with Akonadi 5.14.1 (20.04) https://mail.kde.org/pipermail/kdepim-users/2020-June/013315.html Thing is, while this regression is new, unreliability and performance issues regarding Akonadi are *known* for years. And capable developers spent a lot of effort to fix them. Yet… it still does not work. Some people even started over with the Kube project, but while the architecture of Sink that powers it appears to be more efficient and lean, Kube and Sink only provides a limited subset of the functionality users of KDEPIM use so far. The pity in there is: KMail and other KDEPIM applications are actually quite good. But especially KMail suffers a lot cause it waits for Akonadi to complete a request more often than not. It is a "wait for Akonadi game". The bug reports that describe why this is the case are open since years. I mentioned some of them in above post. I really mean no accusation here for anybody. I know KDEPIM and Akonadi developers are working hard. They are doing their best, I am sure of that. But while the situation intermittently improved some, it is still not really good. Also requiring users to be database administrators to make things work again in case of trouble… is simply a no go to me. Currently I have no idea how to fix the situation. I lack the C++ skills for it and while I can learn C++, in the situations I tried to understand how Akonadi works and where I find what in the code… where I would even start looking about fixing a certain issues… I failed. I know some of how it works, but I never brought it all together. I may be able to learn all of this, but given that even seasoned KDEPIM developers have not been able to really stabilize Akonadi… I feel that the bar is quite high. The bugs that cause the trouble are all reported on bugs.kde.org – many for years already. Again no offense meant. The KDEPIM developers do what they can. At the same time more and more new cool features are developed for Akonadi and KDEPIM like KDE Itinerary or Etesync this. But the foundation still is not as solid as it would need to be for users to have a more pleasant experience with it than many users currently have. It works for some, sure… but just look at the mailing list, the bug tracker and on the internet… many users struggle with it. Including myself… and I defended Akonadi before quite a bit before, despite all the trouble I had with it. I am not defending it now. It is still not working reliably, it still does not perform well for a considerable amount of users. Anyone having any idea how to improve this situation? Could it help to make fixing this up one of the next community goals? I know it is some time till the current 3-year period for goal achievement is completed. What else could help? Best, -- Martin
Re: The chat situation
Hi Nate, hi. Nate Graham - 11.06.20, 01:16:55 CEST: > The current Matrix solution does not seem not optimal to me. I have > really tried my best to be a good citizen and use Matrix as much as > possible over the last year but I find myself gravitating back towards > Telegram because of how much better the overall UX is, especially for > fast-moving discussions and those involving images. […] > This situation really needs to be fixed, somehow. I'm not > knowledgeable enough regarding chat software to be able to propose > solution, but I don't feel like the status quo is something we should > live with. Can we fix Matrix? Or should we migrate to something that > offers a better UX? I am still using IRC. Last time I tried to register for Matrix it put up some Google Recaptcha and is where I lost my interest already. But aside from that, I believe part of the thing is: I am not using *any* chat client from KDE at the moment. Why? There are not up to par with what would be needed: Kopete currently is not even in Debian unstable… and last it was, it wasn't working all that well. And no OMEMO with XMPP either. Also it claims to support many more chat protocols than make sense. KDE Telepathy appears to be abandoned completely. Even Konversation does not seem to receive a lot of attention, or am I missing something? It however still appears to be quite usable. But I am using Quassel IRC anyway… Kaidan.im – I hope it will get there, without OMEMO no option for me. I think this could be one of the next community goals after the currently running 3 years period… fix up the chat software situation in KDE. However for now that won't help. So for now there may be the option to find a suitable combination of *some* chat client, even outside of KDE project, with chat server that satisfies people. I'd keep IRC however until there would be something that could convince all those IRC users to switch over. Thanks, -- Martin
Discontinuing legacy infrastructure
Hi all, As previously announced by Sysadmin, following the Gitlab migration we would be shutting down a number of services that were part of the old Git infrastructure, as they were replaced with our new Gitlab based infrastructure. This is a change which has now been actioned, and means the following: 1) git:// protocol support has now been discontinued Prior to the move to Gitlab, the anongit network offered access to our repositories over both the git:// protocol as well as https://. This has now been discontinued, and access is now provided solely via https to ensure that connections cannot be intercepted and tampered with 2) CGit has been discontinued The CGit instance previously available at cgit.kde.org has now been shutdown and is no longer available. All repository browsing should now take place via Gitlab at https://invent.kde.org/ 3) The anongit network in general has been discontinued Following the migration to Gitlab, all developers as well as automated systems began to use the master server for their traffic exclusively. Load monitoring since then has indicated that the system is fully capable of handling this load without the assistance of any additional systems. To avoid issues that have come up in the past (with people trying to push to anongit, or systems being out of sync) it has been decided that the anongit service is no longer providing benefit to us and as such it has also been discontinued. A legacy compatibility redirector will continue to operate under the hostname 'anongit.kde.org' for https urls and will redirect older style urls to their replacement Gitlab equivalents. If anyone has any questions on the above, please let us know. Thanks, Ben Cooksley KDE Sysadmin
Re: The chat situation
Kenny Duffus kirjoitti 11.6.2020 klo 11.44: On Thursday, 11 June 2020 08:19:21 BST Ilmari Lauhakangas wrote: As an alternative, we can also "fix" IRC, meaning to improve its UX. For offering a KDE-hosted always-online experience to everyone, there are modern solutions such as https://convos.chat/ https://thelounge.chat/ https://github.com/kiwiirc/kiwibnc Of these, KiwiBNC is a general purpose bouncer, which means you can attach any mobile or desktop client to it. Account creation could be tied to KDE Identity. Hi KDE already offers a bouncer https://community.kde.org/Sysadmin/BNC Ok, that is nice, but KiwiBNC would remove the need for manual sysadmin work. Just thinking of a future that is up to modern expectations and without a setup UX requiring acrobatics. Even KiwiBNC still needs work to get rid of the need for command-line style setting up of SASL authentication. Ilmari
Re: The chat situation
On Thursday, 11 June 2020 08:19:21 BST Ilmari Lauhakangas wrote: > As an alternative, we can also "fix" IRC, meaning to improve its UX. > > For offering a KDE-hosted always-online experience to everyone, there > are modern solutions such as > > https://convos.chat/ > https://thelounge.chat/ > https://github.com/kiwiirc/kiwibnc > > Of these, KiwiBNC is a general purpose bouncer, which means you can > attach any mobile or desktop client to it. Account creation could be > tied to KDE Identity. > Hi KDE already offers a bouncer https://community.kde.org/Sysadmin/BNC -- Kenny (Pronouns: he/him)
Re: The chat situation
Nate Graham kirjoitti 11.6.2020 klo 2.16: Carson's email about bridging #kde-devel to Telegram got me thinking: we should have a discussion about the situation we're in regarding chat services in KDE. The current Matrix solution does not seem not optimal to me. I have really tried my best to be a good citizen and use Matrix as much as possible over the last year but I find myself gravitating back towards Telegram because of how much better the overall UX is, especially for fast-moving discussions and those involving images. I haven't found a Matrix client that offers both a half-decent UX and also a reasonable featureset. The service suffers from lag, sometimes severe. Periodically the federation breaks, or the bridge between IRC and Telegram breaks, leading to people's messages silently vanishing. The implementation of the bridge itself impedes discussions between Telegram users and IRC/Matrix users because when a Telegram user replies to a post made by someone on IRC or Matrix, that person person can't see the message being replied to. Overall it just does not feel like a great user experience. This situation really needs to be fixed, somehow. I'm not knowledgeable enough regarding chat software to be able to propose solution, but I don't feel like the status quo is something we should live with. Can we fix Matrix? Or should we migrate to something that offers a better UX? As an alternative, we can also "fix" IRC, meaning to improve its UX. For offering a KDE-hosted always-online experience to everyone, there are modern solutions such as https://convos.chat/ https://thelounge.chat/ https://github.com/kiwiirc/kiwibnc Of these, KiwiBNC is a general purpose bouncer, which means you can attach any mobile or desktop client to it. Account creation could be tied to KDE Identity. What is needed on the UX side is to make sure there is no requirement for command-line style interaction. Ilmari
Re: The chat situation
On Thursday, 11 June 2020 07:20:55 BST Kevin Ottens wrote: > Hello, > > On Thursday, 11 June 2020 01:16:55 CEST Nate Graham wrote: > > Carson's email about bridging #kde-devel to Telegram got me thinking: we > > should have a discussion about the situation we're in regarding chat > > services in KDE. > > > > The current Matrix solution does not seem not optimal to me. I have > > really tried my best to be a good citizen and use Matrix as much as > > possible over the last year but I find myself gravitating back towards > > Telegram because of how much better the overall UX is, especially for > > fast-moving discussions and those involving images. > > > > I haven't found a Matrix client that offers both a half-decent UX and > > also a reasonable featureset. The service suffers from lag, sometimes > > severe. Periodically the federation breaks, or the bridge between IRC > > and Telegram breaks, leading to people's messages silently vanishing. > > The implementation of the bridge itself impedes discussions between > > Telegram users and IRC/Matrix users because when a Telegram user replies > > to a post made by someone on IRC or Matrix, that person person can't see > > the message being replied to. Overall it just does not feel like a great > > user experience. > > > > This situation really needs to be fixed, somehow. I'm not knowledgeable > > enough regarding chat software to be able to propose solution, but I > > don't feel like the status quo is something we should live with. Can we > > fix Matrix? Or should we migrate to something that offers a better UX? > > I've not been a good citizen like you and stuck mostly to IRC so I got a > question out of curiosity (and because I think it'll impact the decision > making). > > Regarding the lags and the breakages, do they happen only to bridged > channels? > Or do they happen also for "pure" Matrix channels as well? > Bridging is the main issue. The community not using things other than IRC would remove these problems. However going back to that state is probably unlikely I think it is unfair to lay all the blame at Matrix's door. Bridged Telegram is a bad experience for users on both IRC and Matrix. While the IRC <> Matrix integration experience is very good, except on those odd occasions when there are problems with the bridge -- Kenny (Pronouns: he/him)
Re: The chat situation
Doesn't Riot.im support images well enough for your use-case? It's free software, and it's becoming fairly mature lately. The root issue for both Telegram and Matrix seems to be that they're bridging through a legacy platform like IRC. Would it be fair to say that this problem will slowly resolve itself in time, as users leave IRC? I don't mean to troll: I've been on IRC myself for 20+ years, but the protocol has been stagnating and clients requires too much setup for newcomers, particularly when you consider identity, presence and persistence. Other open source projects are migrating to Matrix or Gitter, and soon or later KDE will need to make a decision. On 11/06/2020 09.09, Carl Schwan wrote: Hi, Strong +1 on this. The current situation is far from good. Currently to have a good communication application I need to either use a proprietary platform, use a platform who doesn't support images and for which I need to set up a bouncer on my server or use a platform which lags a lot and which doesn't always relays my messages to the bridges. Carl Le mercredi, juin 10, 2020 11:16 PM, Nate Graham a écrit : Carson's email about bridging #kde-devel to Telegram got me thinking: we should have a discussion about the situation we're in regarding chat services in KDE. The current Matrix solution does not seem not optimal to me. I have really tried my best to be a good citizen and use Matrix as much as possible over the last year but I find myself gravitating back towards Telegram because of how much better the overall UX is, especially for fast-moving discussions and those involving images. I haven't found a Matrix client that offers both a half-decent UX and also a reasonable featureset. The service suffers from lag, sometimes severe. Periodically the federation breaks, or the bridge between IRC and Telegram breaks, leading to people's messages silently vanishing. The implementation of the bridge itself impedes discussions between Telegram users and IRC/Matrix users because when a Telegram user replies to a post made by someone on IRC or Matrix, that person person can't see the message being replied to. Overall it just does not feel like a great user experience. This situation really needs to be fixed, somehow. I'm not knowledgeable enough regarding chat software to be able to propose solution, but I don't feel like the status quo is something we should live with. Can we fix Matrix? Or should we migrate to something that offers a better UX? Nate -- _ // Bernie Innocenti \X/ https://codewiz.org/
