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 different. > Nate Kind regards, Christian