Pre-RFC — Call for discussion: Opening a new chat collaboration platform

Development
1

Hello Nix community,

I’d like to initiate a pre-RFC (Request for Comments) discussion regarding a proposed shift in our communication platforms for Nix development. We’ve been using a combination of Matrix (IRC before the Freenode event) and Discourse for a while now, and while they have served us well, it’s becoming increasingly evident that they are not without their shortcomings. This proposal aims to address these issues by considering the adoption of a Zulip instance.

The Current State of Affairs

Our current communication tools, Matrix and Discourse, have played a significant role in our ability to collaborate, share information, and discuss development topics. However, as Nix development evolves, I have encountered several issues that need attention:

1. Matrix Deficiencies:

  • Lack of Threading: The absence of proper threading [1] in Matrix discussions often makes it challenging to follow conversations, especially when several topics are discussed simultaneously. This leads to confusion and inefficiency in communication in channels like Nixpkgs Development or sometimes NixOS infrastructure.
  • Resource Intensiveness and User-friendliness: Matrix is resource-intensive in many ways: the client has became a resource hog on mobile, alternative clients are not always on par for features, (encrypted) messages are lost.

I personally reached out multiple times to Element about our issues and as I understand it now, Element is not in a so-good-shape for working on community issues because of their funding situation. As far as I understand, alternative to Element could be considered but it would be hard to base our productivity platform there.

[1]: The threads as they are in Matrix are semi-broken, and are not rendered by all Matrix clients, they cannot be considered reliable IME and we often ask people to not use them.

2. Discourse Issues:

  • Thread Management: While Discourse offers more structured discussions, its threading model is not always intuitive, making it difficult to track related conversations effectively.
  • Overhead: Navigating Discourse can be cumbersome, with the potential for information overload, making it less efficient for developers who work on Nix on a daily basis. (this is also true of Matrix sometimes.)

Unfortunately, Discourse was not the Mailing List replacement people touted it was as far as I understand it.

Exploring a New Solution: https://zulip.com/

Given these challenges, I would like to submit to the community to consider the possibility of adopting a Zulip instance as our primary chat collaboration platform for developers. Here’s why Zulip may be a promising alternative:

Zulip propose a synchronous and asynchronous chat model with plenty of batteries (video calls, etc.), we lose the possibility of offering to our users to federate with our instance, but it’s not clear this is a feature which benefits people who just want to work on Nix, therefore, I would not say this is an active goal of a collaboration platform for the project, just a nice to have.

Zulip possess mailing list-style threading, albeit with a more modern (whatever you like it or not) web twist to it.

The mobile app is okish and more usable in my experience [2].

Self-hosting is very much possible and I worked on the matter at some point here: Package request `zulip` · Issue #50209 · NixOS/nixpkgs · GitHub and the Zulip developers seems to be interested into maybe using NixOS themselves (??? maybe that’s not the case anymore).
Of course, I recommend to use their instances like we let Element EMS host our Matrix.

Also, I do not recommend removing the Matrix, but would argue that we should carefully examine how to perform a slow transition that is respectful of everyone’s time or that we deem it impossible and accept the statut quo.

[2]: I have been using and/or participating in the Lean theorem prover, Coq theorem prover, homotopical type theory, Rust project, RustCrypto project’s Zulips with better success, for the Lean, even on a semi-daily basis at some point in my life (and I remember a smoother experience, though working on mathlib is kind of like working on nixpkgs, except you swap package for mathematics).

Considerations for the Community

Before proceeding with any changes which should probably go via RFC, it’s essential to gather feedback and insights from our active developers. I want to maintain a platform that suits the needs of our community and if most of our active developers are not interested or see alternatives or prefer to explore different solutions, I believe it would be nice to express them here.

This pre-RFC discussion serves as a starting point to gauge interest, concerns, and opinions on transitioning to Zulip or exploring other alternatives. I am completely open to suggestions, and I want to make this decision collectively, ensuring it aligns with the majority of our developers’ preferences.

Alternatives: Mailing Lists

While we aim to improve our sync and async chat collaboration, it’s worth mentioning that mailing lists remain a viable alternative for async. However, I understand that some developers might prefer a chat-based platform over mailing lists due to its immediacy and convenience.

I, for one, also prefer mailing lists for asynchronous chat collaboration, but I use NeoMutt on a daily basis, I also realize this may not be a consensual opinion and may drive off developers.

In conclusion, our current communication tools, Matrix and Discourse, have served us well, but they are not without their challenges in my humble opinion. This pre-RFC discussion is an invitation to all Nix developers to share their thoughts on a potential transition to Zulip or other alternatives that might better suit our evolving needs.

Thank you for being part of the Nix community and helping me make informed decisions for our collective benefit.

20 Likes
2

Having used Zulip a lot recently in the Lean community, I find it a decent tool for tech-savy users for synchronous communication, and it might fit the nix community well. I don’t see it as an alternative to Discourse, which (to me at least) fills the role of the async communication forum – like IRC + Mailing list a few decades ago.

11 Likes
3

100% in favor of trying Zulip for chat, not sure it’ll replace Discourse entirely for longer form stuff, but I think the only way to really find that out is to try.

8 Likes
4

Zulip is pretty sweet, but also somewhat young. For example, subscribing to threads was only implemented a few days ago.

I’m sorry for the state of Element. I wish it was better implemented, because, otherwise, I like it.

I like how Matrix is a single global “place” where everyone seems to have a single account regardless of what rooms/spaces/communities they’re in. You don’t have that with Zulip. Zulip instances seem completely isolated from each other. Not sure how much of a down-side this is.

7 Likes
5

I’m personally -1 on this proposal, I feel like the motivations behind the change don’t overcome the cost of the change itself, and they will fragment further communication + leave some people behind (esp. in the case of mailing lists).

Can you be more specific?

So instead we’d switch to a platform that just doesn’t support alternate clients, and requires Electron on desktop?

Are you suggesting that support would be happening on other collaboration platforms, or am I misreading this? I definitely don’t want to have to care about multiple platforms for Nix related stuff, nor do I think that the distinction between “user” and “developer” can be clearly made in many cases.

I feel like you’re missing here that most collaboration is actually happening on github, which is also an async communication mechanism, and by far the biggest one in use for Nix*. Discourse isn’t the replacement for mailing lists, GH issues/PRs is.

My experience trying to contribute to any other project that still uses mailing lists in 2023 says “no”.

15 Likes
6

Re: mailing lists: :nauseated_face: sorry

I haven’t found much to complain about Discourse. But I haven’t been using it intensely.

1 Like
7

Yes, of course, there were long running bugs around threads in Matrix, regarding notifications (I’m not even sure they were fixed it, I just stopped having OCD on unread notifications coming from threads).

Threads on Element are difficult to notice, I very much often miss them, I believe fellow developers reported similar pains.

Finally, they are not built to have a threaded focused discussion on something, their area is super small to talk over there AFAIK.

Doesn’t Matrix mostly requires Electron to be used right now? Apparently, if you don’t want to lose all your encryption keys all the time because of browser disk space policies or browser state corruption, you need to run the Electron Element app or need to use an alternative client.

In my experience, you basically cycle through alternative and you come back to Element because it’s more or less one of the thing that is battle tested and supported.

No, I am suggestion to perform slow transition and moves to avoid fragmentation but this is indeed not a figured out part yet. You are totally right to say that the cost could be too large.

Interesting take on this, would you suggest then that we should build automation to offer people a way to filter to the firehose of issues and PRs? Because I definitely agree that this could be the right replacement.

Though, it does not fix threading, GitHub issues still doesn’t allow trivial threading and we still have sometimes people blocking discussions by just getting in the middle of the discussion without any easy recourse to split off the discussion, which is what mailing list still solves and GitHub does not, atm.

Of course, this does not show up in any normal contribution, but this can show up in some difficult / hard / controversial PRs / issues and it would be helpful to have this tooling.

That’s a fair opinion and one I am looking for, via this post, thank you!

8

Yes, to clarify, we would replace probably Matrix, not Discourse.

2 Likes
9

Unless we’re going to bridge Matrix and Zulip, how will this not just fragment the community further? We already have Matrix, IRC, and the unofficial Discord, so we’d have a fourth chat option with this proposal? While I realize bridges aren’t ideal, I’d personally rather see us use them to combine our already disparate chats instead of adding another.

I would be against moving to mailing lists. I prefer Discourse to managing a firehose of email threads. I find it easier to track issues I care about on Discourse, and prefer the display format to any mail client I’ve used.

6 Likes
10

It’s definitely the federation and silo problem, I am annoyed about that too, but the benefits we have from that are unclear for active development, they are clear they lower barrier for anyone to join our rooms and participate in the discussion.

It is… a benefit and also an interesting problem in my experience.

2 Likes
11

Apologies, I did not make clear that I would recommend slowly moving to Matrix and removing it once we feel this is time. Fragmentation is inevitable and I would be a conman to say this would never happen with any moving proposal.

But doing nothing is just accepting the statut quo.

Brutally moving everyone is losing people in the process.

My proposal is that we look carefully at how to perform the transition in a respectful way of everyone.

We can definitely bridge Matrix and Zulip, bridging though do bring some issues w.r.t. to feature parity.

6 Likes
12

-1 here as well, Matrix is just starting to mature with Element X and such, why would we abandon Matrix just to go to another premature software that also relatively young? Furthermore, not a big fan of the centralization model in general, and it seems Zulip encourages that a lot more than Matrix does. I understand self-hosting is possible but not really actively encouraged unlike Matrix, and creating, 10000 different accounts for each service. Some people created Matrix accounts solely for NixOS, why would we just pull the rug on them and force them to create a new service? Furthermore, I understand that you recommend against pulling Matrix support, but it’s not feasible to support two platforms at once and especially would not be convenient. Another thing is privacy, NixOS focuses on privacy and security, the Matrix protocol focuses on those things and I at least personally find that critical, Zulip is a good slack replacement, not a good Discord-like replacement. Another thing to note is that other FOSS projects use Matrix, making easy communication between projects pretty easy with Matrix. We would lose that with moving to Zulip.

7 Likes
13

In my experience, I did not experience any improvement with ElementX which BTW crashed and forced me to go back to Element.
You just proved also my point about how Matrix is unreliable about their launch and their “product management”.

This is not sustainable for people who needs to work, this is not a matter of “let’s just suck it up and everything will be fine later”, this has been like this for some time now. Every day is a bit more infuriating than the next one.

Matrix and Zulip have different objectives and therefore a young software (which is used by large projects BTW, e.g. Rust or Lean) can be more mature than older software (Matrix).

This is interesting; how does decentralization bring value to the active developers working in nixpkgs?

It is true and fair, but I honestly prefer much more the tradeoff of creating a N + 1 account and be done (or better: use OIDC) than dealing with daily issues just because now I have my own homeserver and decentralization stuff. Again, if this is a minor concern (is it a major concern for you as an active developer, can you elaborate on the specifics?), I do not see the problem.

Do you have data on this and what is the audience of people creating Matrix accounts solely for NixOS? It is unfortunate but the proposal here is to discuss ways to make it easier for the next time, e.g. use proper SSO, for which Matrix, is still broken BTW.

This is true but any proposal would require progressive transition, it is possible to pull this off, but would definitely require some amount of consensus. Hence, the discussion.

I am not certain how privacy factors out in this, if by this, you mean you want to avoid telemetry, for sure, we can explore this problematic. If you mean encrypted messages, I am not so sure Matrix is better at this given that I often say to the people sending messages to me to disable encryption because it’s broken.

NixOS does not particularly focus on privacy and security more than any distribution of the same type, BTW and not sure how does it factor out in a discussion that is particularly interested into better tooling for the active developers (also related but support channels are very complicated to handle in Matrix IME).

Finally, I don’t understand the Slack vs. Discord discussion, it does not really make a lot of sense to me. Can you clarify?

Sure, like I mentioned: Lean, Coq, HoTT, Rust, RustCrypto and probably many more I am forgetting which are all FLOSS projects (yes HoTT is a FLOSS collaborative project around a book.).

I get your point that being in the same network / protocol means that you can trivially go to another place and chat, I do this all the time on Matrix, while I see the appeal, I do not see what is the actual value provided by this colocation and how does it help us to take upon us the difficulties that Matrix is imposing on us. If you can make your point about this value, I would be interested.

14

Love the initiative & think Zulip could work really well for our community! :two_hearts:

Two features I’d like to highlight:

  • Instances can be open, so that the don’t require any form of authentication to browse and search history of public channels. See i.e. https://rust-lang.zulipchat.com for an example of a large technical community which is completely public.

  • Email-Integration works surprisingly well in both directions.

Can you explain what you mean by “relatively young” or “premature”? Zulip has been in development since 2012, according to Wikipedia that’s older than matrix the protocol.

“Subscribing” as in e-mail subscriptions? Because you did get notifications in the ui for new messages in threads since at least 5 years ago.

4 Likes
15

I’ve been hoping and rooting for Matrix for a long, long time now. And I hate the idea of giving up the single-account, federated dream. Experiences with numerous mass-internet-properties lately have made me very wary of anything not-self-hosted (I know Zulip is, see the open nixpkgs request :wink:) or not-federated.

But I’m also sort of exhausted for the hope I’ve invested. It’s paper-cut after paper-cut with the overall user Matrix experience. Not least of which is the implementation of Threads, versus how Zulip handles them, or how Discord handles the “forum” concept of rooms that are all thread based. I’m tech-heartbroken over it, and as idealistic as I am, and as much as I still have “run my own homeserver with bridges so I can stop using Discord and WhatsApp clients” on my TODO list… I also can’t bring myself to invest further given the overall stability of the ecosystem being what it is.

Personally, (1) Today, I +1-ish commented on an old synapse Issue that is causing Element to dual-notify me regularly. (2) Yesterday I was getting 403 errors when sending to a room I’m in. Element didn’t bother giving me any useful information, but digging into the logs revealed that Synpase thinks I’m not “in the room” despite the fact that I clearly am. (3) ElementX is fast, but I pretty much have to restart it and re-navigate to a room regularly because it just loses history it had been showing me minutes earlier, randomly. (4) It hasn’t happened recently but despite my technical skills, I have had countless E2EE issues over the years.

I really like the community around Matrix, the ideals, the idea of bridges, but I wouldn’t question a single person from wanting to look elsewhere at this point. Especially as “things” keep piling up and I just want my underlying, necessary tools to work.

Also, keeping up with Discourse and Matrix is becoming expensive as the community grows. The thought of having threading with Zulip, to skim conversations, read the ones that interest or concern me and discard the rest, sounds like a dream.

11 Likes
16

I support this enthusiastically; Zulip is easily my favorite of the established, synchronous community chat platforms I know.

3 Likes
17

+1 for Zulip.

Matrix seemed like a good idea. I wanted to like it. But the constant friction has slowly eroded that goodwill for me. I am ready to try something new.

With an open-source system, that has SSO, and where public backups are available, we can move hosts in case something bad happens. That replaces some of the interesting aspects of federation.

The main downside is for those who live in the Terminal and use WeeChat. I don’t know if there is a good solution for them.

4 Likes
18

Well the nice thing is that fixing weechat-matrix is probably harder than having weechat-zulip IMHO.

Of course, there’s a big elephant in the room: threaded discussion in IRC are just simply not a thing, they are mostly channels but Zulip has metachannels and channels.

I think people living in their Terminal (like me) are probably better served with the official Zulip terminal client: GitHub - zulip/zulip-terminal: Official Zulip terminal client. (didn’t try, not an endorse)

3 Likes
19

I am one of these people; I only created my Matrix account to be more closely connected with other people working on Nix.

And I really don’t mind creating another account for Zulip. That’s what I have a password manager for.

I’d say let’s try it.

8 Likes
20

Generally against this. I don’t think it matters what we use. IRC worked, Matrix works, Zulip would also work, and so would pretty much anything else. Sure there are some differences, but nothing major, they all get the job done.

But switching this is really expensive in so many ways:

  • Somebody needs to actually implement this, setting up the server, migrating the Matrix channels, setting up bridges or whatever, …
  • Everybody needs to learn how to use Zulip and switch workflows
  • We might be losing history in the process
  • We’ll be losing people in the process. Even with the previous forced IRC migration we lost some people that never bothered installing Matrix. Some people won’t think Nix is important enough for them to switch chat services.
  • Just discussing this and getting everybody to agree on it takes a lot of time
  • Probably more I’m not thinking of right now…

I don’t think the Nix community has enough resources to go for that right now. There’s a million problems with the Nix ecosystem, and Matrix is on that list, but it’s far down the list imo. I’d rather people spend their time on more important things.

19 Likes