Should we run a Matrix server?

Hi,

We would basically act as another token for the Matrix Foundation, their Open Tech Will Save Us series being basically a nice libre software developers public discussion. I'm saying this as a bitter Nomagic user whose admin has strongly held opinions about politics and IT, but who was happy to show up and present how he used Matrix as a kitten.

In reality, the Matrix Foundation optimizes for engagement and it's a pity to come home, be greeted by cats, and ignore them to stay involved in a conversation whose real-life purpose is made secondary by the Element client's “delight” : a team paid by investors and rewarding interactions with its interface.

A saner “protocol” would be XMPP : there is about 500 XEPs (and IETF RFCs, for starters) and 4,000 MSCs. This obviously increases the cost of developing a brand new Matrix client and I only see a glimpse of light near Ruma, which provides free code (as a library) for developers. This narrows the Matrix users' client choice : some other mainstream ones don't even show modified messages properly! As a matter of fact, even if there's much more interest for Matrix, there are also fewer clients…

I know Ginny used Zulip a while ago and maybe we should try it out, but honestly I've been confused about our use of Matrix since I've come back and heard about it.

I would be in favor of trying it!

Can it be funded? Matrix servers seem expensive. Still, I am excited about this, as it seems social.coop is becoming "not just" a mastodon instance, after joining meet.coop

Other question: Are apex domains for both mastodon and matrix handles possible, or would it require a subdomain? evan:social.coop vs evan:matrix.social.coop

I know that Nomagic uses a subdomain due to LDAP (a centralized way to manage credentials, i.e. one username/password per co-owner across all services) but otherwise it's possible to serve contents on the same FQDN, so-called "domain" (but on a different port) or on the same port (but on a different FQDN).

In other words, it's possible to run a Matrix server on the same domain as a Mastodon instance because they don't use the same ports.

Cost-wise, Conduit is a small, efficient server that I expect to be ideal at our scale. The only issue in terms of server performance is Synapse, the legacy Python implementation, but it's been hard to develop something else because again, 4,000 MSCs.

I'd support it and would likely use it. I think Matrix is interesting and potentially important. This feels like a quite different thing, but complementary and in the same vein as the mastodon instance. That said I'm not sure I could contribute to maintenance myself.

Hi Flancian. Is the main benefit that we would be able to use social.coop in our IDs for branding when speaking to others on the Matrixverse? I ask, as I've not been left with the impression that we've outgrown the room we currently have on the matrix.org homeserver.

I proposed this years ago and would be very much in favor. I'd love to make Social.coop my primary Matrix instance, rather than Matrix.org. I have also had the experience of running a Matrix server (via Cloudron; we use a it for internal coordination at my lab), and it has been fairly low-maintenance.

Without diving too far into my dislike of everything Matrix, I'd like to also suggest that we consider other chat protocols. Matrix is a large, VC funded protocol (that opened a foundation after receiving criticism of the way they're run, but it's all the same people and accounts) that ignored years of community consensus building to re-invent the wheel and did a bad job of it (but had the marketing budget to convince people otherwise). Matrix is a bad chat protocol, with mostly bad clients and servers, and I would be extremely sad if social.coop used something like it instead of an IETF standard or other more community driven solution.

I use matrix a fair bit and am hugely in favour of people owning their own tech via coops. So in many ways I'd be very happy to have an account on a matrix instance thats owned & run by a co-op of which I'm a member.

However its my impression that matrix servers take a significant amount of server and sys-admin resources to keep running smoothly. I imagine we could cover the server costs and/or raise more funds as necessary - but I'm concerned about the possible burden it could place on our sys-admin volunteers.

I know a fair few matrix servers where the sys admins have struggled keeping matrix running well and spent a lot of time trying to massage it into behaving. Also a few where they gave up and closed the service.

I havent been paying as close attention last couple of years and possibly there could of been improvements that make things easier for matrix/synapse sys-admins.

I'm against rushing into this without getting a much better idea of how things are currently for synapse (I dont think, still, any of the other matrix server implementations are properly production ready?) sys-admins & ideally having a few people with the necessary skills committed to keeping the service up and running.

This is an old discussion and I haven't been active in the social.coop community over the last couple of years, so feel free to ignore this. But I'm going to chuck in my 5 cents anyway.

First, a little context. My comments here reflect my experiences as an early adopter/ power user, I'm not a developer nor a server admin. I was an XMPP champion for many years, starting back when it was called Jabber. More recently I've done a little bit of paid contracting for Snikket, a project to build a unified UX on top of existing XMPP software (so far Prosody, Conversations, and Siskin). I've also been an active user in the matrix-verse (mainly Riot/ Element but I've experimented with a few other apps) and spent a couple of years following the development of the project. So I think it's fair to say I can comment on this topic in a fairly non-partisan fashion.

From a user POV, matrix is clearly the better choice for federated chat right now. Both direct chats and group chats are easy to start in matrix apps, and there are apps for all major OS platforms (and the web) that reliably support file transfer, voice/ video chats, and E2EE (including verification of other users). Most XMPP apps are relics of the late 1990s, and their support for modern chat functions like creating groups chats, file transfer, voice/ video chats, and E2EE, is patchy, although some progress has been made on this in recent years. Snikket apps significantly improve the UX of XMPP, and may eventually be a better choice than matrix, but it's a fairly new project with limited resources, and so far it only has apps for Android/ iThings. At this stage, the Snikket server is only distributed as a Docker image, so whether that's a good choice depends on your opinion of Docker. Snikket apps (or the upstream apps they build on) can be used with any XMPP server, but this can affect the quality of the UX, depending on how the server is configured.

I've debated XMPP fans many times in the fediverse on the topic of matrix, and most of their criticisms boil down to the server performance of Synapse. It's true that Disroot and some other community-hosting organizations switched from matrix to XMPP for chat, because of poor server performance. But the matrix folks openly acknowledge that Synapse, as a prototype, has significant downsides. It's also true that its performance has improved significantly over the last couple of years since Disroot made that decision.

So the question for social.coop is what's more important, making live easier for users, or for server admins? If it's users, the best choice, for now, is probably matrix. If it's admins, the best choice is might be XMPP. One option could be to stand up one of each for a limited testing period, so the social.coop community can evaluate both, from both user and admin perspectives, and then make a final decision on which one to use as an ongoing service.