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