Re: The chat situation
Am Mo., 15. Juni 2020 um 02:03 Uhr schrieb Valorie Zimmerman : > > It is very nice, and the team are great people. I went to one of their > sessions a few years back at a GSoC Mentor Summit. Thinking about using it > for the KDE community, I asked them about bridging to IRC. They said that > they had tried and given up. > > Without a way to bridge with IRC, I don't see how we can use it, no matter > how attractive it is. > > Valorie When in doubt, check Matterbridge for your bridging needs. Supports basically every single chat protocol one can think of. IRC, Matrix, Discord, Telegram, XMPP, you name it, it supports it. And sure enough, it supports Zulip as a service to bridge with. -- Carson Black [ jan Pontajosi, appadeia_ ]
Re: The chat situation
On Sun, Jun 14, 2020 at 3:40 PM Ihor Antonov wrote: > On Wednesday, 10 June 2020 16:16:55 PDT Nate Graham wrote: > > ... > > Has anyone considered Zulip https://zulipchat.com/ ? > > Rust community uses it a lot, and it has THE BEST threading support ever. > > -- > Ihor Antonov It is very nice, and the team are great people. I went to one of their sessions a few years back at a GSoC Mentor Summit. Thinking about using it for the KDE community, I asked them about bridging to IRC. They said that they had tried and given up. Without a way to bridge with IRC, I don't see how we can use it, no matter how attractive it is. Valorie
Re: The chat situation
I've seen it used in a few circles. However if I had to suggest something, definitely Mattermost. I've used it when I worked with the EFF and for a minute, I thought it was something like Slack. It is but on steroids. It is written in Go and React but the likes of Uber also use it. On June 14, 2020 10:39:51 PM UTC, Ihor Antonov wrote: >On Wednesday, 10 June 2020 16:16:55 PDT Nate Graham wrote: >> ... > >Has anyone considered Zulip https://zulipchat.com/ ? > >Rust community uses it a lot, and it has THE BEST threading support ever. > > >-- >Ihor Antonov -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: The chat situation
On Wednesday, 10 June 2020 16:16:55 PDT Nate Graham wrote: > ... Has anyone considered Zulip https://zulipchat.com/ ? Rust community uses it a lot, and it has THE BEST threading support ever. -- Ihor Antonov signature.asc Description: This is a digitally signed message part.
Re: The chat situation
Am Freitag, 12. Juni 2020, 22:13:09 CEST schrieb Andras Mantia: > Hi, > > On Friday, June 12, 2020 11:03:30 PM EEST Christian Loosli wrote: > > We use it at work with one our partners, and I was pondering to set it up > > for a project I am involved in (no, neither KDE nor freenode) where we do > > not want to use Matrix. Do you happen to know by chance how well it > > bridges? These are a requirement (Telegram and IRC, mostly). > > Documentation > > on that seems to be a bit stale / sparse, unless I am missing something. > > Unfortunately I have no experience with bridging it at all. > > Regarding using it in KDE (I know you asked for another project): Yeah, by coincidence it would also have been mostly valid for KDE. Time for me to spin up docker on one box and install it then, I guess. Thanks anyway :) > I'm not > convinced for a project as KDE any of the alternatives mentioned would be as > easy to use as freenode, most of them need an account, self hosting, > managing probably a lot of users and a big database, and has the problems > you mentioned about the legality of storing the conversations. Neither am I. Hence I'm pretty sure that no matter what solution we choose: it will contain multiple protocols / solutions, or it will alienate people for very valid reasons and fragment us, which I'd rather avoid. So I'd prefer fixing the papercuts in the existing solutions, and fortunately aside from Telegram (where only the client is) every thing we use is FOSS and specified (fsvo for IRC, I am aware), and we are a rather big communtiy with lots of devpower, so we should be able to. Or throw money at it if we really have to. > > Andras Kind regards, Christian
Re: The chat situation
Hi, On Friday, June 12, 2020 11:03:30 PM EEST Christian Loosli wrote: > We use it at work with one our partners, and I was pondering to set it up > for a project I am involved in (no, neither KDE nor freenode) where we do > not want to use Matrix. Do you happen to know by chance how well it > bridges? These are a requirement (Telegram and IRC, mostly). Documentation > on that seems to be a bit stale / sparse, unless I am missing something. Unfortunately I have no experience with bridging it at all. Regarding using it in KDE (I know you asked for another project): I'm not convinced for a project as KDE any of the alternatives mentioned would be as easy to use as freenode, most of them need an account, self hosting, managing probably a lot of users and a big database, and has the problems you mentioned about the legality of storing the conversations. Andras
Re: The chat situation
Am Freitag, 12. Juni 2020, 22:00:58 CEST schrieb Andras Mantia: > Hey, > > On Friday, June 12, 2020 12:50:25 AM EEST Martin Steigerwald wrote: > > 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. > > Rocket Chat has its share of problems, it can suffer e.g from lags and the > clients (except Ruqola) are using a lot of memory. Ruqola is already usable, > but not so pretty yet (sorry guys ;) ). > Otherwise feature wise Rocket Chat is nice. I don't like its (or Slack's) > threads, but YMMV. We use it at work with one our partners, and I was pondering to set it up for a project I am involved in (no, neither KDE nor freenode) where we do not want to use Matrix. Do you happen to know by chance how well it bridges? These are a requirement (Telegram and IRC, mostly). Documentation on that seems to be a bit stale / sparse, unless I am missing something. > Andras Kind regards, Christian
Re: The chat situation
Hey, On Friday, June 12, 2020 12:50:25 AM EEST Martin Steigerwald wrote: > 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. Rocket Chat has its share of problems, it can suffer e.g from lags and the clients (except Ruqola) are using a lot of memory. Ruqola is already usable, but not so pretty yet (sorry guys ;) ). Otherwise feature wise Rocket Chat is nice. I don't like its (or Slack's) threads, but YMMV. Andras
Re: The chat situation
Am Freitag, 12. Juni 2020, 07:09:01 CEST schrieb Nate Graham:
> 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.
There will always be incompatibilities if you bridge multiple protocols, no
matter which ones they are. And given the survey results I doubt that we will
ever find the one single solution that makes everyone happy.
Others tried, others failed, and I can't see how we could do any better.
> Because if Matrix
> can't be better than the two things it was intended to replace, then
> it's not a success, right?
It was not supposed to replace IRC, but rather extend it, like kate and
kwrite.
Unless we run our own, non-federated instance of Matrix and develop two
clients for it, I highly doubt that IRC can be fully replaced.
Can't say much on the Telegram end as I don't use that the same way I use IRC
/ Matrix, but I'm pretty sure power users there will find similar arguments.
We had that discussion, in length, with surveys and votes.
So instead of doing this yet once again, maybe we should focus on papercuts
that can be resolved, and I think most of the papercuts mentioned can.
> 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.
I don't see how we could avoid that. Either we run our own instance, then it
costs us time, or we have a sponsored instance, then it costs someone else
time. Either we develop fixes ourselves, which costs us time, or we have
someone else develop them, which costs them time. And in case of it being a
business (like our matrix instance sponsor sort of is), time means money.
As for the papercuts mentioned:
- lag and bridge issues could most likely be bettered a lot by what Kenny
mentioned, but this has to be done by our Matrix folks. From what I
understand, we did ask them to and poke, but nothing happened, so maybe we
should poke again. I don't mind the e.V. doing that, I don't mind throwing
money at it if that is needed, but I think it should be possible without.
We might also have to discuss again how exactly we bridge Telegram, currently
we do Telegram <> IRC <> Matrix while Telegram <> Matrix <> IRC might be
more wise. That could start hitting limits on the IRC side, but for the KDE
bridge these can be raised if needed.
- Registration issues due to the IRC bridge ("can't write to / join channel"):
We can solve that on our end most of the time simply by not requiring our IRC
channels to be for registered users only. I recommended that a couple of times
and helped fixing it where it was still the case. If there are still such
channels, I also gladly help out there. I am not aware of any, though, so I
don't know why this came up.
If we do have to force registrations (e.g. due to a spam attack by someone
unhappy with KDE) this could be fixed by making the process more straight
forward on the Matrix end, which requires some development effort in Matrix
clients, but it can be done, it's not like freenode Nickserv changes behaviour
often (close to never).
- Protocol incompatibilities: mostly fixable on the Matrix side, there are
various feature requests open on their end (e.g. when it comes to Telegram
stickers), all of this is feasible since Matrix already stores documents
anyway, so it can just point a link to the document (graphic, video, whatever)
for protocols that do not allow it. It also already handles message lenght
restrictions, not perfectly, but it handles them.
What always will be an edge case is the different protocols having different
ACLs, e.g. if we get Telegram spam (and despite Telegram requiring a phone
number to register, we quite often do get Telegram spam) an admin in the
Telegram group should handle it. This can be semi-fixed by bridging with a
connection per connection (which brings other, new issues), so that e.g.
Matrix could ban a spammy Telegram connection, or IRC a spammy Matrix
connection (this is already possible), but in the end, we'd probably need to
find decent ways of administrating stuff across bridges.
Again, I don't think that switching to a single protocol / product works,
Mozilla tried, Mozilla communities are now spread over 3 protocols, one split
in two places. That's hardly what we want to achieve. And I doubt that we can
bring every person to be happy with one single product, requirements per group
(e.g. VDG) are simply too
Re: The chat situation
On 12/06/2020 14.09, Nate Graham wrote: 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. Could KDE e.V step in to negotiate a support contract, and pay for features or bugfixes that the KDE community requests? Just a random example: KDE could ask them to link accounts with identity.kde.org, removing some friction of having to create an account on matrix.io, or another Matrix instance. -- _ // Bernie Innocenti \X/ https://codewiz.org/
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 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 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: 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
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
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/
Re: The chat situation
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 publickey - carl@carlschwan.eu - 0x7F564CB5.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
