These requirements will be used to select the shortlist of chat technologies that we will evaluate in detail. The only apply to the evaluation process itself and don't imply an automatic decision to drop our current official chat infrastructure (IRC).
We could extend this exercise to deciding on the priority of other features, but let's focus on what's absolutely essential for now.
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
I would also believe there are pre-requirements. Like being Open Source and Free. And not a Shareware or Premium-freeware (Means need to pay to have full features).
Here's an initial attempt to list our basic requirements. Other factors can of course be taken into account - this is just the absolute minimum that we expect.
Basic features
Private one to one messages
Private group chats?
Public channels, browsable through a directory of GNOME channels
"Persistence" (server-side logs)
Inline media (primarily images, but maybe also video too)
Accessibility (need to better define what this means - high contrast, screen reader, etc)
Considering how the matrix bridge manages to make IRC worse for IRC users, I'd rather not make bridging a requirement (in particular as IRC already manages to be quite bad on its own, thank you very much).
And if we really want the feature, then I'd want an additional requirement that the bridge must not worsen the experience of IRC users. That includes turning entire conversations into URLs that force you to switch between web browser and IRC client continuously.
Well this conversation has been stalled for a long time. Our community will remain split between three different chat platforms (IRC, Matrix, and now Rocket.Chat) if we don't make progress here.
A native desktop client
Some of the features/options which might make committed IRC users more comfortable (UI density, etc)
I think this is where you're going to lose a lot of developers if you underestimate the importance of these two requirements. If we don't have a GNOME desktop client for our selected chat platform that presents everything in a comfortable compact user interface comparable to polari or fractal or dino, then I'd say we have failed badly. I won't idle in a web UI all day like I comfortably do with IRC, it's just not going to happen. I would sign on to respond to pings if the pings come with email notifications, and I'd sign on when I want to discuss something in particular, but without a desktop client I won't be signed on constantly during the workday.
Requiring a native GNOME desktop client doesn't mean we stick to IRC forever. We have three: polari (IRC), dino (XMPP), and fractal (Matrix). And we could theoretically write one for Rocket.Chat, assuming the Rocket.Chat protocol is good enough. (I suspect there's a reason why nobody has attempted to do so, though.)
Finally, I'll add that I expect significantly increased acceptance from developers for solutions that offer a choice between web and desktop client. It'd be nice to find a chat solution that can actually be accepted by a large majority of the community, not just the half of the community that prefers web clients or the half that prefers desktop clients. In particular, it would be really nice to not wind up with developers using IRC while engagement team and Foundation staff use Rocket.Chat for its web UI. Let's do both desktop and web UIs, and do them both well, so we can unify the community on one platform everyone will accept.
And we could theoretically write one for Rocket.Chat, assuming the Rocket.Chat protocol is good enough. (I suspect there's a reason why nobody has attempted to do so, though.)
The existence of a Rocket.chat plugin for libpurple is excellent news, but I am fairly confident that Pidgin is not the chat experience we want to get out of this evaluation. So, while a plugin for libpurple exists, development effort is still required to create a client frontend that aligns with GNOME's UI guidelines and UX expectations. This certainly is not impossible, but I am not aware of any projects making this effort a reality.
I thought that the bridging item could be controversial! I should have started a separate issue to discuss it, really...
In some respects I don't think that this matters too much for the selection process, since I think that most of the options do support IRC bridging.
I understand why people have objections to it. At the same time, I do think that it's good for us to have IRC bridging as an option, particularly when we consider our migration strategy and having options available to us as we move forward.
Would bridging IRC into the new chat system be acceptable? Matrix has an IRCd implementation in development that would let you do that (connect to a Matrix server from an IRC client).
Would bridging IRC into the new chat system be acceptable? Matrix has an IRCd implementation in development that would let you do that (connect to a Matrix server from an IRC client).
(i.e. the complete opposite of what we have set up now on gnome.modular.im.)
At the same time, I do think that it's good for us to have IRC bridging as an option, particularly when we consider our migration strategy and having options available to us as we move forward.
This is not something other projects, like Mozilla, have done when migrating their chat infrastructure.
AFAIR, Mozilla is leaving the door open for a Matrix/IRCd implementation for the people that still wish to use their IRC clients, but the whole point was to close off the irc.mozilla.org server.
Additionally, I want to emphasise that an IRC bridge will never result in a migration, or us moving forward, as it by necessity requires an IRC network not only to be used, but also its continued existence; if the point of the migration is to have the community move off of IRC (as much as we can) to a new chat platform, then we gain nothing by having a bridge in the first place, as there won't ever be any incentive to move off of irc.gnome.org.
Putting it in other words: we migrated from mailing lists to Discourse not by having Discourse bridging topics by sending and receiving emails to existing mailing list, but by telling people to send and receive emails to Discourse.
This is absolutely correct as long as you have that bridging on it will continue to be used. Set a deadline - and hopefully some of the people who moved off first will write tools, scripts whatever they were used to on irc to work on the new platform in text mode.
(whatever the platform is, it is clear that it needs to have a text version and not just a native client)
So I took @aday's list and pared it down to a smaller set. I moved "accessibility" into a category under Client, as accessibility really becomes a set of features supported by the client. I left off Linear Metrics; that feels more like a set of criteria against which each potential candidate software could be evaluated.
I also added GTK Desktop client as a requirement. GNOME is a desktop environment. We should be pushing ourselves to use our own software as much as possible. If you disagree with this sentiment, I would love to hear why. Let's have a civil discussion about this!
If I may add supporting proposal. I suggest we restrict this proposal to only GNOME. That means that we do not apply this to GTK. Let GTK use IRC - there is a fairly clear delineation between GNOME and GTK (comms and website) and most GTK developers prefer IRC rather than the other way around. It might be worth doing a survey just to see what people think between the two communities but I think the data is going to reveal that this is probably correct.
Then officially, we move to whatever the solution we decide for GNOME is given the above requirements and we turn off all bridging and let irc be irc. All GNOME channels move to the new solution and we leave IRC.
If someone wants to start moving to matrix for GTK then that can be a separate effort.
A bit of progress on that issue: there is work currently being done by the people at Element to address the issues we have with the bridges.
The main complaints we could gather from IRC side are:
it seems long messages or multi-line messages are truncated and turned into URLs for IRC people, which is extra annoying
it seems to be (have been?) spamming IRC channels with entering/leaving messages when there is a bridge restart
quotes are common with Matrix, but seem to make the experience terrible on IRC side
edits are often interrupting the conversation on IRC side
We’re addressing 1. by disabling the URLisation of long messages for a test period. If this is a problem in the long run the alternative is to show the beginning of the message and then an URL to get the whole message.
There is a potential solution for 2. which has drawbacks. It would consist of some "lazy init" of the people on IRC. This means the bridge would create the IRC user (which represents a Matrix user) only when a Matrix user wants to send a message. This has the drawback of having IRC people not knowing who from Matrix is actually in the room. It’s probably best to rely on filtering capabilities of IRC clients.
Let’s have it running for at least a few days and see if the experience is "less terrible enough" before we set hard requirements on bridges.
We should also fix Matrix dropping PM replies from unregistered users with no indication that there is a problem. At the very least, one side or the other ought to receive a warning that the messages are being dropped.
As this is a very crucial aspect of our community I am taking over this issue with the hope that it will be solved in a few months.
I am adding the basic features and requirements from older conversations to this issue. These are the requirements that we currently want our platform to have and I would like your feedback on them. If you have any new suggestions or changes please comment them here by the 14th of February and I will use the final list as our official requirements.
Here you can read the plan for how we will handle this initiative in terms of transparency and approach.
Access from IRC clients (note, not bridging to an existing IRC server) isn't in the requirements?
Not that I'm wholly representative of what users we want joining our chat servers, but because of involvement in other Free Software projects (and work), I'm already on a number of other IRC networks, which I'll need to keep being on, and I'd rather not need another messaging client.
I imagine that the long term plan would probably result in this. But I can't imagine we shutting down the bridge in the next 1-2 years since it would be disruptive. And to be honest I do not use IRC but I do understand the importance of the bridge right now :)
I really don't understand this reasoning. You're talking about the Matrix/IRC bridge as if Matrix was already selected as the chat service we'd want to use.
My comment was that it would be nice if the solution included the ability for IRC clients to connect, ideally to an IRC server that's tied to that service so that our sysadmins don't have to maintain 2 different chat services side-by-side as well as the link between them.
My comment was that it would be nice if the solution included the ability for IRC clients to connect, ideally to an IRC server that's tied to that service so that our sysadmins don't have to maintain 2 different chat services side-by-side as well as the link between them.
Gotcha. I believe I misunderstand you then. Yes, agreed!
You're talking about the Matrix/IRC bridge as if Matrix was already selected as the chat service we'd want to use.
Uhm, sorry if I made it sound like that but no, I was giving an example based on my personal opinion.
This is really a client thing, and I'd say it has little to do with evaluating the chat systems we use.
A web or terminal IRC client might not support system themes, but a native client could. Or a native client could choose not to support theming.
One thing I would add as an important requirement: Allows collaboration across communities. Similar to @hadess, I use Matrix to chat across multiple free software communities I'm involved in.
@kristiprogri I think we should add "No support / use of outbound IRC gatewaying" as a functional requirement - or perhaps... , or essentially erase the requirement for gatewaying. It provides at beast a very poor version of the chat experience for those on the other side of the gateway, and at worst interacting with rooms hosted within IRC (and the need to interact with legacy IRC behaviours, services, etc) presents an extremely hostile user experience and barrier to entry.
I have little opinion on "inbound" gatewaying (ie, a system that pretends to be an IRC server and lets clients connect) other than I'm confident it will present a terrible experience to IRC adherents due to the impedence mismatch. Put another way, if we added a column for "System via IRC gateway" it would not meet the majority of the requirements we are apparently evaluating/comparing all of the systems on.
We also need to add "Federation can be restricted to trusted server operators who agree to assist the GNOME Foundation enforce the Code of Conduct and other regulatory issues such as data retention". The reason is that federation implies responsibility for identity - eg a "bad" server can (actively, or passively) enable the creation of false user IDs to evade bans or other moderation controls. We need to know who to hold to account on any federated servers and that they will respect and respond to the GNOME CoC process, GDPR deletion requests, etc.
Also, it's unclear to me what "Ability to dense message history" means, and is it intentional that "Free software version" is listed separately to "open source version" - ie is there a specific "freeness" metric being pursued here, or is this a drafting error? It could be clearer.
What I meant with the "ability to dense message history"is to not have a limitation on how many characters or words the message should have. Just wanted to make sure here that users will be able to see and understand everything.
I also removed the open source by the end of the drafting. It was an error, what I meant is already included at the"Free Software version".
I am sorry for that,my English was not clear enough.
I think we should add "No support / use of outbound IRC gatewaying" as a functional requirement - or perhaps... , or essentially erase the requirement for gatewaying.
I agree with that as a target. Since we (hopefully) cannot coerce anyone into our systems, that means change management needs to happen, with a carefully crafted transition plan.
I’m really convinced that bridges worsen the experience for everyone and that they should be removed. But I’m also really convinced that if we removed them out of the blue we would lose a part of our community.
Bridges are bad, but they can allow a plan like the following:
Onboard people on the new platform, but keep the ability to talk with people from IRC
Make the premium experience on the new platform, and keep IRC as a legacy system. If discomfort has to happen, it needs to happen on IRC, not on the new platform
Eventually remove the bridge when at least 3/4 of the community is on the new platform
This also requires some work to have new platform "champions" or "ambassadors". Those would be people who were used to IRC and loved it but are convinced that the new platform can have benefits for the GNOME community as a whole. Their peers will be most likely to listen to them than to "those folks from Engagement/Foundation".
I think we should add "No support / use of outbound IRC gatewaying" as a functional requirement - or perhaps... , or essentially erase the requirement for gatewaying. It provides at beast a very poor version of the chat experience for those on the other side of the gateway, and at worst interacting with rooms hosted within IRC (and the need to interact with legacy IRC behaviours, services, etc) presents an extremely hostile user experience and barrier to entry.
I know it's very poor, but we have really no alternative. The hypothetical inbound gateway you describe simply does not exist (at least not at a sufficient level of quality) today. Our crappy outbound gateway at least mostly works. Too many developers have promised they will simply stop communicating with the rest of us if we move away from IRC. So if we want to avoid making the existing community split problem even worse, the existing bridge is not optional. At least not at first.
Thibault is trying to fix problems with the bridge in this issue. It will never be perfect, but perhaps with some increased investment we can improve things to the point that we don't have to have a split between IRC and Matrix. Such a split would be far worse than the status quo.
@ramcq I think this is a great point - I think if folks come into our matrix/gnome ecosystem that it requires they sign the code of conduct. There should be a mechanism for that. That could just be a matrix bot perhaps that detects new connections. Not sure if a block all, allow or allow all, and block lists are better. I worry that a block all, allow list might be hard to maintain vs the other.
Since I know you enjoy Matrix, I assume that's what you have in mind when commenting above. When people sign-up on the Mozilla instance they already have to sign a CoC, so no need for a bot for that, it's already built-in :)
@sri I'm talking about ensuring the co-operation of federated server operators, not end users. We need the fedarated server operators needing to agree that they will help us enforce the COC if needed, at least on larger servers where eg if we wanted to ban the entire server due to some botnet attack (or whatever) we would also lose 100s of legitimate users. I don't really have anything against federation - I spent years working on and promoting XMPP but it's a fact that it dilutes identity/trust because you are trusting the /other/ admins by accepting a federated connection. On anything that's not a personal server with a handful of users, we need an escalation path in place. I think in practice there are going to be a handful of big "free world" servers which will be happy to agree to that if we have a discussion, and then a bunch of noise which is probably fine to accept, but I don't know if there is an automatic way to draw that line, or we need to start with blocking all and building an allowlist through a process.
It seems that LF is also offering matrix/element chat hosting as well. This is a good time to start talking with operators of each of these and see if we can have binding agreements to enforce the CoC. Especially since I'm working on pushing matrix/element in the ecosystems I'm involved in (open system firmware, openbmc, etc)
What I'm having trouble understanding in all this is that, you don't need to ask other servers to enforce our CoC, since if one doesn't respect the CoC in the GNOME community spaces then this person will just get banned/kicked. I mean, we can't make email providers enforce our CoC on lists.gnome.org mailing lists, I don't see how it would be possible to do it either for Matrix. And since All participants in GNOME community spaces are subject to the Code of Conduct (https://wiki.gnome.org/Foundation/CodeOfConduct#Scope, matrix being already included in the list of community spaces), there's no formal signing process needed. Maybe I'm just mistaken on what's this about (maybe I am?), but I don't see why it's needed nor how it feasible either.
Agreed. I also believe going whitelist first will be harmful to a very import goal of this initiative: newcomer-friendlyness. Right now anyone on any server, whether self-hosted or ran by someone they trust, can join our rooms and get help. By locking ourselves behind an additional account on a walled network, we'd be losing out on a massive number of potential contributors.
A real life example can be found in our experimentation with Rocket.chat, which was initially advertised as a public official chat. We saw very little engagement from new contributors there. Meanwhile on Matrix and IRC we have a fairly steady flow of people looking to enter the community.
Right now anyone on any server, whether self-hosted or ran by someone they trust, can join our rooms and get help. By locking ourselves behind an additional account on a walled network, we'd be losing out on a massive number of potential contributors.
I agree so much. Using a whitelist/blacklist is effectively breaking federation's whole point: anyone should be able to join any server's room from any server they want.
A sidenote from that: in the case of an obviously evil server crafted for the purpose of spam, it's important to be able to completely stop interacting with that server.
Allowlists (or whitelists) are actively harmful against federation and the flow of newcomers, denylists (or blacklists) are a good tool to help with moderation. In the very last resort (which means definitely not as part of the usual moderation routine), even shadowbans make sense.
This can't be emulated client-side by allowing a client to use multiple accounts. There is no way I can create a Matrix account on :mozilla.org or :igalia.com, since they are restricted for employees only. :matrix.tabos.de is the personal server of one GNOME developer; I guess it would probably go away if :gnome.org were to block federation.
We can mix members of different servers into different private rooms. We have one private Epiphany developer room with members of three different homeservers. It is secured, so only room members can see the chat (or malicious server operators, but end-to-end encryption is available to us if desired). There is just no way this flexible communication would ever be possible without federation; maybe we could convince everyone to sign up for :gnome.org Matrix accounts, but we cannot plausibly expect them to be checked as often as their existing workplace accounts.
And federation exists on :gnome.org's Matrix server today. Turning off an existing feature that we have come to rely on would be quite unwelcome.
I understand the primary concern regarding federation is moderation, but I also don't understand because Matrix should have sufficient moderation tools to meet our needs already. Enforcing the GNOME code of conduct on other servers is unrealistic, but it should not be hard to enforce on :gnome.org. Certainly, it should be a lot easier than the status quo on IRC, where unregistered users are the norm and it seems we are utterly incapable of blocking obviously abusive content like sex bots. In the hopefully-rare event that we are ever unable to address specific moderation issues from specific problematic servers using our existing moderation tools -- which I understand should already be powerful enough to enforce the GNOME Code of Conduct on :gnome.org -- then we can denylist the specific problematic servers. Allowlisting will not scale. Asking two server operators to get together and agree to interoperate and agree to new code of conducts whenever two people want to chat together just doesn't make sense.
Right so while I'm not sure to what extent my opinion matters I can state I have found Rocket.Chat as a very convenient way for reaching out and having conversions with community members and staff so I would found it a shame if the platform would go away. I think there no overstatement that Rocket.Chat have worked quite well for the engagement team at least.