Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC 0094] Use Matrix for Official Chat #94

Merged
merged 4 commits into from
Sep 2, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
63 changes: 63 additions & 0 deletions rfcs/0094-use-matrix-for-official-chat.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,63 @@
---
feature: use-matrix-for-official-chat
start-date: 2020-05-19
author: @ryantm and others
shepherd-team: @grahamc, @joepie91, @andir, @mweinelt
shepherd-leader: @grahamc
---

# Summary
[summary]: #summary

Switch from IRC ([Freenode](https://freenode.net/)) to [Matrix](https://matrix.org/) ([#community:nixos.org][1]) as our official community chat.

# Motivation
[motivation]: #motivation

The former official community chat host, Freenode, has collapsed. Many Free Software communities have abandoned it, so its network effects have become negative instead of positive.

There have also been long-running usability and accessibility issues with IRC as a platform, for the general public. This is further supported by the existence of a large (1000+ users) unofficial NixOS community on Discord. The NixOS community as a whole would benefit from moving to a more broadly accessible platform with modern features.

While there are quite a few options in this area (for example Discord and Slack), using an open platform is quite important for a FOSS project like NixOS, and Matrix stands out here—it is federated, has a very active community and development process, *and* also provides modern features and polished clients.

While the move to Matrix has de facto already taken place, as a necessary response to the imminent collapse of Freenode, this RFC is intended to evaluate and formalize the decision, and ensure that community concerns around the move are addressed.

# Implementation
[implementation]: #implementation

We will use [Matrix](https://matrix.org) as our official and primary chat platform.

The NixOS Foundation will operate a Matrix homeserver on the `nixos.org` namespace.

A collection of rooms will be listed under the [#community:nixos.org][1] Space.

Any other places that point to IRC will be updated to point to Matrix instead.

Any convenience features such as bots and monitoring will be ported to Matrix as needed.

The official Matrix rooms will be configured such that their history is publicly visible, unless there are strong reasons not to do so. Additionally, Matrix allows for third parties to set up a search-engine-indexable public log viewer.

## Bridging Matrix and IRC

Repeated interest was expressed in a bridge between Matrix and IRC. This RFC does not address the implementation details of bridging, but considers bridging to be a near-future goal, and proposes that a new RFC be drafted to work out the details.

In any case, to avoid a mismatch in cultural norms stemming from having two connected platforms, the Matrix side would be the 'primary side' of the bridge, with the IRC side serving as an access mechanism for those unwilling or unable to use a Matrix client. This means that, for example, Matrix-specific features may be used in the NixOS community even if those bridge awkwardly to IRC, and that all community moderators should be on the Matrix side.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On FreeNode, anyone can create new channels how they see fit. This allowed informal groups to be created without having to ask for permission.

Is it possible to create arbitrary channels on the new server? If not, what is the process to handle that?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In principle, rooms (channels) are not tied to any server in matrix. They can have one or multiple aliases though for easier discovery and addressing, like #nix:nixos.org is one.
These aliases can be added later as well, allowing groups to form, grow under a non-official alias like #nix-toasters:hardwarehackers.town until they ask an admin of the nixos.org matrix server to give them an alias for that server as well, and add them to the space.

It might make sense to explicitly state this in the RFC and lay out a process, though.

Copy link
Contributor

@joepie91 joepie91 May 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rooms on Matrix do not exist "on a server" - they are replicated to all servers which have participants in the room. Anyone is free to create a room, and any amount of addresses on any homeserver can be pointed at it, and it will exist independently of the availability of any given homeserver.

I believe the default permissions required to 'claim' an alias on a homeserver (such as #somename:matrix.org or #somename:nixos.org) are 1) has admin access to the room, and 2) is using an account on the homeserver in question.

Addition to the Space is something that would only be possible to do by people with some form of administrative access to that Space.

# Drawbacks
[drawbacks]: #drawbacks

* Long-term IRC users might find it difficult to get used to a different chat platform and client. However, we consider the aforementioned benefits to outweigh this drawback.
* Participating in the conversations requires an account on a homeserver. However, due to the many publicly usable homeservers and the ability to self-host a homeserver if so desired, we do not consider this to be a significant concern in practice.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Presence data is much more chatty in Matrix and can be turned off on the server level. For large rooms, it might be a good idea to do that. Especially since it leaks some level of personal information. But it's tunable only on the server level the last time I looked into it.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Presence is enabled on a per-server basis. If you do not want presence data, then you can use a server that doesn't support it. Matrix.org, for example, currently doesn't support presence notifications because they are so expensive computationally.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sumnerevans Both of you are correct:
You're talking about the explicit sending of presence as a being available or not flag being broadcasted. That can indeed be disabled.
@zimbatm is likely talking about the read state marker being moved forward, which can be used to infer user presence.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can presence not be turned off on a room level? Even if I turn it off on my server, the sync will still broadcast other people's presence and take up a lot of space.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zimbatm it depends on what kind of "presence" you are talking about. If you are talking about read state, then that's not possible to disable at all.

If you are talking about the "presence" feature (which shows users as available or unavailable in the UI), then that can be disabled on a per-server basis, and it will ignore all presence notifications coming over federation, and will also not send out any presence notifications.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is an open issue for disabling read reciepts: element-hq/element-web#2527

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Support for MSC2285 (hidden read receipts) just landed in Synapse v1.40.0rc1. Here is the PR: matrix-org/synapse#10413. And here are the release notes: https://github.com/matrix-org/synapse/releases/tag/v1.40.0rc1

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Plain text is easy to log to a file; to copy around; to pastebin; to store in any number of cloud services; and to read, and to grep, even in the absence of one's chat client. The richer format of Matrix messages may make these tasks fundamentally more difficult, or perhaps more reliant on cloud services.

Relatedly: For freenode we have had @samueldr's public logs. How will those be migrated to serve Matrix, or what will replace them? If they're replaced by something offered by Matrix (e.g., @kevincox suggests "We can allow guests to view"), do we know...

  • What is the log retention policy? Is it anything less than @samueldr's? I hear Matrix.org is too overburdened to retain logs long-term.
  • Does the replacement have the features of the existing logs (search, linking to a specific message)?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is https://github.com/matrix-org/matrix-static for logging which we can supposedly just run our servers or use the hosted instance of matrix: https://view.matrix.org/room/%21sgkZKRutwatDMkYBHU:nixos.org/

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In case the home server instance hosted by Element becomes unavailable, users who had their accounts on that server would lose access to their identity and history. DMs between those users would be lost. Therefore, at least one admin account should be hosted on another home server.

/cc @sumnerevans

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is probably good to make clear that the DM is only lost if both users were on nixos.org. And of course the users can be storing backups.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These suggestions perfectly answer all of my questions. Having them in the RFC text is a good idea. Thank you.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alternate wording suggestion:

Suggested change
The nixos.org homeserver is currently hosted by Element. In the event that that home server becomes unavailable, users who had their accounts on that server would lose access to their identity and history. DMs where all users are on the nixos.org homeserver would be lost. Therefore, at least one admin account should be hosted on another home server.

# Alternatives
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can also consider bridging the Matrix room to IRC networks as well as possibly the discord room. The downside is that neither of those bridges support "fancy" features such as reactions which may make the conversion confusing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which always results in degradations of chat quality on one side, which is why I would be very careful about bridging in general.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree but I still think that it makes sense to consider it as an alternative.

As a Matrix user I prefer the non-bridged option but that is clearly a biased stance and telling everyone to behave the way that suits me the best. So to ensure that we pick the best option overall it is important to weigh the pros can cons of the different options.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there's a difference between "Matrix user uses a bridge to talk in an IRC channel", vs. "the community is on Matrix but an IRC interface is provided through a bridge".

In the former case, the baseline to compare against is "only native IRC users", whereas in the latter case the baseline is "no access from IRC at all". So long as the messaging around this is clear, I think that imperfect IRC access is better than no IRC access.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The more I think about it, the more I feel that the RFC should at the very least mention IRC bridging.

I think it's desirable to have this (with the understanding of it being a Matrix-first room, feature/convention-wise), not just to improve accessibility for a certain part of the community, but also because "my system won't boot and all I have is netcat" is a realistic problem for someone trying to access a distro room to have, and IRC can work in this scenario.

Libera does not currently have an operational bridge, but likely will in the future. OFTC already has an operational bridge today.

[alternatives]: #alternatives

1. Switch to another IRC network like [Libera Chat][2]
- This would not address the aforementioned usability and accessibility concerns.
2. Switch to a proprietary chat system like Discord or Slack
- Being proprietary, this would fit NixOS poorly as a FOSS project, provide very little control over the community space, and pose accessibility issues.
3. Switch to an open-core or open-source system like Zulip, Rocketchat, or Mattermost
- This would require people to create a dedicated account for NixOS, as they are more-or-less isolated systems; whereas many community members are already using Matrix, and can use their existing (federated) account.

[1]: https://matrix.to/#/#community:nixos.org
[2]: https://libera.chat/