Ement.el is a Matrix client for Emacs
Have not tried it myself yet (but have migrated from weechat to rcirc and like it so element.el is next to try).
Can you be more specific about the accusation? While I think I can easily defend why Element clients are really broken, latest example I saw Hector Martin: "We've been using Matrix a lot for Fedora Asahi an…" - Treehouse Mastodon.
But then, that is interesting because I think you are pointing to the right problem. For people who doesn’t do daily development, this is not such a big deal, for sure. But for me, who deal with this on a daily basis, losing messages means ignoring stuff, sometimes for months, because social cues regarding pinging people are not easy. Sometimes, we repeat and we lose important information.
Async long-form discussions are meh in Discourse because of the lack of being able to arbitrarily thread in the discussions, sometimes, someone just send something that drive the discussion off the topic and I would like just to ignore it and get back to the topic and let people discuss to the death any interesting digression.
Maybe the good solution is to use more aggressively split-off thread in Discourse?
I would not say this, I think the statut quo is just burning out people too. But I agree that the negative downsides are: we lose also other people, we spread further the community, etc.
Either case, it points at the fact that we need to solve the real underlying problem of enabling collaboration cross-platform in a way that is satisfying.
I think you are exaggerating the situation, I was present during the Freenode situatio, and I was in a lot of channels, what do you mean by “was in a fast downspiral” ? Now, I agree that people believed it was important to address it in a fast fashion, and they used this opportunity to do some interesting changes.
And I am thankful for them organizing those operations, etc. But I reject the story there was an emergency.
The current situation is that we (I and some people) lost significant productivity with the constant bugs that Matrix offers to its daily users. Beyond the fact, this is strenuous for daily developers who didn’t overengineer their setup or didn’t decide to rewrite a custom client for themselves (yes yes.), there is no imminent urge.
But I don’t think I am pursuing innovation with the proposal, I have renounced any “niceties”, this post is about asking a collaboration platform that fulfills its basic features, I do not know if people understand that we are this level of brokenness with the platform (maybe because it works for them and they don’t use it as often as the other developers?).
But I understand that people prefers the convenience of the federation ecosystem, nevertheless, some energy has to be spent to examine our options and routes with respect to the platform.
For example, we have no plan if tomorrow EMS decide to drop us or Matrix/Element has serious issues that would degrade the continuity of this protocol on a large scale (e.g. “no money left anymore, it has failed”).
I can’t run it on my x200 (neither can run Element). It’s too complex to have a source build on Nixpkgs. Its closure is massive for a chat app:
nix path-info --closure-size -h $(which zulip)
/nix/store/flhwx7b94xq21f8pvvbgzinl6gvarxkj-zulip-5.10.3 1.8G
See My resignation from freenode and a gazillion of posts wrote during this period.
Here’s the discourse thread where part of the migration has been discussed: Join us on Matrix at #nix:nixos.org (Migrating from Freenode)
To me, this is inherent with chats. They’re not bug trackers. The noise to signal edit: signal to noise (
) ratio is pretty low, they’re impossible to follow for some people (like me).
I’m using Zulip for some other orgs, from my perspective, it’s a good chat system (again, I personally greatly prefer it to Matrix and IRC), but a terrible bug tracker replacement.
You’re asking for a change requiring people to get familiar with yet another chat platform and install some new software running on their computer to interact with the NixOS folks. This is as much innovation as the migration to Matrix originally was.
Overall, I feel like you and I have different needs when it comes to chats. That’s fair. I’m not saying your needs are not relevant, I’m voicing my opinion and personal use case here 
I’m sure I’m not the only one in this situation.
Anyways, my opinion is voiced, I won’t derail this in a endless bike-shedding conversation. Overall, I’d prefer not changing the chat channel. But if we end up moving to Zulip, I’ll move there like I moved to Matrix on the first place. OFC, after ranting a bit 
5 Likes
Maybe GitHub - zulip/zulip-terminal: Official Zulip terminal client. this would work 
— though it’s not an explicit goal to support X200-grade hardware (I recommend upgrading to a X2100 ).
But understandable.
I meant about the accusations regarding how Zulip is a trash client, but, if this is a resource matter, this is a different story.
Yeah, but what we need is not really a bug tracker neither. Bug tracking is often the consequence of a focused topical discussion. We have GitHub to fill bugs.
But this loops in what I said earlier about project management and @samueldr nailed it when I chatted about this with them.
I agree that synchronous instantaneous chat have inherently a memoryless property but this is also the result of a lack of inappropriate tooling.
Yes, I am not proposing it as a bug tracker, but more as a tool for focused / topical development discussion of a large organization.
For sure, and thank you for your voice! I am not sure if we will move to Zulip given the responses yet.
I feel like it may be worth it to try to experiment bridging with the existing via Zulip and see how it works for other users.
2 Likes
Can you elaborate on this? I’m pretty happy Discourse-as-Mailing-List user, I prefer reading discussions in my email client (since you have proper threading there) and occasionally also reply using email, but mostly using web interface due to markdown preview. Having the possibility to use both is quite nice. According to How do I use Discourse via email? - FAQs - Mozilla Discourse it should also be possible to create new posts, but it seems it isn’t enabled for our instance/categories.
2 Likes
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.
You have used some experimental implementation of threads. The proposal has only recently been accepted into the standard, so no wonder all clients did not agree on the implementation.
- 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.
Debatable if with Matrix you mean Element. Matrix as a message protocol should not matter much on the performance of the client. With Matrix at least you get more choices of server and client software, not sure with what you’re proposing.
its threading model is not always intuitive, making it difficult to track related conversations effectively.
Again, this debatable: discourse was designed to keep the conversation on track using a flat (non-threaded) style. The theory is that you should start a new thread if you feel the conversation is becoming confusing to follow.
In general, unless there’s a dire need, I’m against changing the platform even if the alternative is superior on paper. Migrations to a different system (either issues, messaging or forums) are almost guaranteed to complicate the discoverability of information, which is already in a very sorry state for NixOS.
3 Likes
Yes, I meant Element by this, in practice, I won’t rehash why alternative clients are also problematic, I tried all of them: Fluffychat, Cinny, etc. Sometimes, they are better, sometimes they degrade superfast, you have to switch, you lose messages, etc.
No, there’s no client flexibility in my proposal, I am not convinced of the advantages of client flexibility brought by Matrix because they are not really working well in general.
In any case, the point stands: Element is a resource hog on mobile, alternative clients are not necessarily usable, etc.
“Matrix as a message protocol should not matter much on the performance of the client”, as someone who write chat messaging protocol software (not for Matrix, but for IRC), I beg to differ. But this would send us in disgressions.
Right, but it’s not as frictionless as sending an email with a new subject.
Yes, but, I think the discoverability of information is very related to the tools we use, nothing is going to improve magically if we use things we have no control over or require significant amount of work from people who are already actively working on something else. If we do not get more resources to work on those problems, it will just take infinite time, maybe sufficient time we will switch to something else, before we get to work on it.
In the past, we had Discourse not sending some emails - #31 by talyz — I don’t know if this is solved, I may retry indeed, but this was not magic alas…
1 Like
Yes it is. I remember this as I was asked to switch off the mailing list mode. It was a problem of a hosted instance, where only paid plans were allowed to send that much mail. I’ve tried nixpkgs-packaging Discourse myself but failed - that was later solved by @talyz and our instance is now hosted by Flying Circus (many thanks for that!). I would like to see even more of NixOS infra self-hosted since we have packages and modules for most of the popular software and NixOS itself is great for self-hosting the infrastructure.
Regarding creating posts in categories via email - maybe that’s something that “just” needs to be enabled. Possibly @zimbatm knows.
2 Likes
Have you looked into Mattermost? Some projects that I’m a part of (Rocky Linux, Alma Linux and Pop!_OS) use it as the “IM chat” platform.
I’ve briefly used Zulip with the Rust for Linux project and the thread organisation felt a bit unintuitive (or maybe different). It is a nice idea to have only threads and no “general chat” but if given the option, I would prefer the way Mattermost does it (you reply to a message and that starts a thread).
I think Mattermost is Zulip, but with an emphasis on more Slack-like UI, which I am afraid that most of our users are not interested in.
I worked in a large Mattermost at some point, and it was also quite complicated, client flexibility was quite poor at that time and I fear it is still the case, at the moment.
You can have a “general chat” but it’s usually unwanted at some point.
This reminds me, F-Droid only has the beta version of Mattermost but the stable version of Zulip. This may be a problem for OCD driven folks like me.
I’ve turned off the Discourse chat experiment. It feels way too barebones to replace the vibrancy of Matrix.
7 Likes
Tangentially, from the ol’ IRC days, for larger communities there was usually a “this is how you get connected to IRC” guide (and still is, for the dwindling number of communities that actually still use IRC).
Since one of the main reasons for this initiative seems to be that matrix still has (pretty severe) issues, maybe we can have some kind of official matrix survival guide somewhere? It’s ironic to need guides like this given that matrix is more-or-less intended to remove this initial barrier from the IRC days, but it’d at least be helpful. We could even document “supported” clients so that threading can actually be used reasonably.
@Dandellion shares some good notes, at least having the limitations of the platform be less nebulous and infuriating for those among us who don’t want to learn how it works in detail would probably help a bit. And for those who actually self-host homeservers, knowing conduit exists would probably help alleviate the resource problems.
1 Like
The appid is rnbeta but the version is 2.9.0 which is a stable version.
Aren’t Zulip a resource hog? And Element X may improve the situation. And you can always use IRC, XMPP, Telegram or whatever via the bridges. Everyone can use their favorite clients and network. They can also choose their server. If a homeserver is blocked in China they can use another one. But for zulip there is no choice. You want to force everyone into a single network with a single client and a single server.
Zulip has some advantages, but only for few users. Most users are not in the chat to work. They just want to ask some questions. Zulip provides nothing except complexity to them. Given that Matrix is much more popular than Zulip, I (and maybe most users) still need to have a Matrix client and switching the Zulip only takes more resources. And the Zulip client needs to be installed only for NixOS. I thought you can always create a Zulip orgnization for NixOS and see how many users will switch. If most users still stay on Matrix I see no reason to force them to switch.
2 Likes
Yeah. It’s a shame that Matrix’s zulip-style-threads never happened.
2 Likes
I am strongly sceptical of this proposal. My main concern is that federated ecosystems and the cross-pollination of communities and communications within there is a real gem, and we should be really careful when thinking about dropping out there to not value short-term hopes over longer term ecosystem effects.
For me, moving to yet another different Electron chat client would automatically imply less participation and worse reachability.
What makes matrix and other open protocol bases both great as well as complicated/ rough at some edges is their diversity – and the actual possibility for this.
While Raito has the opinion that you effectively need to use Element for proper participation anyways, all I can say is that I only use different non-Electron clients on my personal devices. No need to discuss this any further, but I’m definitely much happier than having to use yet another Electron hog (that’s currently just a wrapped AppImage in nixpkgs).
The Nix(OS) community is very diverse, has different needs and works within different environments. Folks are e.g. working on NixOS mobile. Optimising community participation only for the seemingly common cases (e.g. Zulip Android currently requires Play services for proper notifications) does not suit this diversity.
To be honest, I remain sceptical of the amassing complexity of the distributed state resolution database disguising itself as a chat service. But another side of that is that so much development has already happened or is in progress right now. On the client performance side, there is ongoing work on a higher performance less bandwith client API. Zulip on the other hand just has yet another REST api only for chat client communication. This is how Matrix started as well, then over time became aware of the shortcomings of this in some szenarios.
With Zulip mainly being yet another product managed by a single company, we are mainly dependent on their product decisions when it comes to how that ecosystem evolves.
So please, really think hard about dropping such flexibility and gems when you cannot be certain that certain improvements might just happen if you wish hard enough.
8 Likes
I do share the overall opinion that Matrix is not just something to be discarded because it’s not materializing the features the community is looking for yet, and I think a lot of folks around here probably have at least similar mindsets - after all, we’re on the NixOS discourse here, we have our own problems with the age old tradeoff between ideological long-term goals and short-term practicality.
But the fact that non-Element clients with support for threads don’t exist seems to the core pain-point causing frustration, so using non-Element clients really isn’t a solution to this particular issue (yet). I understand the frustration, Element has been developing slowly for years now, and while this seems like a small amount of time to someone like me who feels stuck in 2020, I think someone actively using Element for productivity (and particularly an individual who presumably has to manage and follow many disjoint threads constantly) over the last couple of years has a valid point here.
I should also add to that that I’ve never found thread features in chat clients particularly useful personally, even when I’ve been in similar positions where I needed to keep track of many conversations, which makes my opinion even more skewed.
I think there’s a real difference in use case, users like me who are mostly passive appreciate the wide scope of different projects you can browse with little effort through Matrix, and don’t mind the performance issues anywhere near as much, while @RaitoBezarius probably actually needs better tooling for their day-to-day work. We’re possibly optimizing too much for the first group.
While I think abandoning an established platform is a bit much in response to that, there should at least be some compromise. I think that’s the conclusion the thread has more or less arrived at anyway, though I’ve not read all of it; In the inverse case, I’d be all for some kind of bridge solution as well.
3 Likes
1 Like