If your free software communications can only be done thru US-based, proprietary options, then you are not free software. To think open source is ideal for your project, but not the tools surrounding it misses the point of trying uplift support & usage of these free sorts of projects (& this isn’t even starting with the privacy & lock-in concerns). Instead of coding around flaws in Microsoft GitHub or building Discord/Slack/Telegram bots, actually build & upstream integrations into the free options as you would like to see folks do unto your own project. Not saying you can’t have these services as an alternative, but as the only option (or the primary option to IIABH) should be shamed & definitely not considered the norm.
Also Matrix is pretty shit, where all the clients/servers run too heavy, & eventual-consistency means self-hosting storage often ballots into ‘too expensive’ which has led to de facto centralization the project cannot fix by design. Meaning Matrix is a better, but still bad chat option.
IRCv3 for accessibility if I need it to be centralized & TLS is the only useful encryption (such as a public chat room); otherwise XMPP + OMEMO for decentralized (but also is great for public chat rooms). No need to reinvent battle-tested, mature standards.
Yeah I’ve used jmp.chat before, but I couldn’t get any of the clients to work well with my pinephone’s microphone. Shame, since it’s the closest you’re going to get to VoIP on the thing.
You could switch some of the problems with perf in switching away from the Python implementation server as well as Element clients but these support the most up-to-date features & the majority of users are now relying on these features that often don’t degrade graacefully.
The bigger issue is eventual consistency. Eventual consistency will not scale for small self-hosting. Every message & every attachment for every user in every chatroom they have joined must be duplicated to your server. This is why joining rooms sometmies takes 10 minutes. Even if you make this async from the client side instead of the current long wait, your server & storage are still taking the hit. A lot of small collectives had to drop their servers for performance & cost (read about yet another one today on the Techlore thread at c/privacy where now only Discord is used for realtime coms). This model is required to copycat the ability to search the entire history like the big, proprietary chat apps such as Slack/Telegram/Discord, but they are centralized so it is easier to manage—but its overuse for all announcement & trying to replace forums turns it into a black hole for information. Your small community probably does not need persistent chat like this—persistent info is lighter & easier to crawl as feeds & forums. With medium-sized servers shutting down, only the biggest & smallest hosts are still kicking with most metadata is largely centralized around Matrix.org who also hosts some of the other larger instances.
If you agree that chat can be chatter as well as ephemeral there is lightweight centralized chat in IRCv3 with TLS has most of the features you need with a longer legacy & massive choice for clients & XMPP for lightweight decentralized chat with a long legacy, client options too, & can be self-hosted in a bedroom on a toaster in comparison which increases the chances of self-hosters & decentralization. These were built in a time when we didn’t have such wasteful taste in tech since they needed to be efficient & only sip power/data in comparison both for clients & servers & storage. The bigger question IMO is what are fundamentally wrong with these two mature options that we need a new option built on unextensible JSON & Israeli Intelligence money?
Well, in their FAQ the Matrix team states that they love both IRC and XMPP and that for those whom these options perform better they wish the best of luck continuing to use them. Matrix does have some qualities they do not and they do not mean to compete with them, rather to put up bridges so as to federate between these decentralized protocols.
Personally, I want to move away from communicating through Discord with many of my friends. I do not believe neither IRC nor XMPP would entice them, but Matrix could as soon as they finish implementing their new video call capabilities. The same goes for community projects that use Discord as a replacement for forums.
Entice how? Spinning up XMPP on any hardware is simple to federate with you—& I wouldn’t wish they all self-host Matrix instances. XMPP’s jingle protocol works for voice/video & I use it self-hosted with my partner. What are the others missing considering the weight of the applications is literally felt. If you want a web client with stickers & reactions (& calling), what is Movim missing? Replacing forums is a part of the problem, not something to replicate… Movim & Libervia cover community posts that are web searchable.
I have no experience with the last two options you mentioned, but I was of the understanding that XMPP does not have video group call functionality. Also, it has been a long time since I used XMPP at all, but syncing history between sessions was not possible to me then. These are features that would be deal breakers to miss.
History / sync is known as message archive management (MAM) & every normal modern client & server supports it. OMEMO uses same double-ratchet encryption & multiple clients as Matrix (with the same old client key dropping issues sadly). By default it does not support groups you are correct, however, FOSS Jitsi (& Zoom for that matter) is powered by XMPP under the hood & can be stood up by yourself.
Personally three of my circles have opted for separate Mumble servers for voice coms (I run one of them from my living room) as video is only ever rarely needed & the system resources is minimal. Having web cams on is seen as a chore & distraction sometimes. The only time video is helpful in my experience is screen share which is different—but screensharing is the worst tool for trying to do code pairing / debugging a terminal using upterm provides a crisper view experience, lower data/system requirements, & observers can optionally drive the remote session.
Did not know about MAM, but that sounds great. I also hosted a Mumble server for my friends for over 5 years, but it was basically never used because there existed a one-stop solution (Discord) that allowed for more stuffTM. TIL Jitsi was powered by XMPP, thanks. I personally have no problem with fragmenting functionality between different specialized applications, but it will always be a tough sell for those I know because they believe they can have it all in their cool app.
At the end of the day, communication services usefulness are upwards limited by the people you can reach through them. The need for everything to be easy and centralized for the user (ironic with respect to server federation, I know) is what has made me so hopeful for the Matrix protocol, since it is designed for allowing this while still being decentralized at its core.
One of my longer-term goals is to integrate Mumble on XMPP (others have thought about this too) since its chat is pretty shit & needing accounts to join isn’t great but or two good foundational protocols.
XMPP is better for modularity which is why everything is at extension with means the foundations are simple & easy to implement where you can build something optimized & bespoke on it like Fornite’s coms or Nintendo’s presense. It’s a little harder to understand tho since out of the box you get almost nothing—but the big servers intended for chat like Prosody & ejabberd have sane defaults.
The centralization you are referring to seems more a client issue since the protocol & servers already ‘do the things’ but it sounds like you want a single ‘app’. For community building where you consider group calls less common, both Movim & Libervia offer more than Element (note the other Matrix clients are lacking feature parity) since they both can do integrated posts like forums—where Libervia supports calendars/events too. There’s no reason a client couldn’t exist with Jitsi or Mumble integration.
Ultimately use the right tool for you—it’s just nice to dispel myths that Matrix has some special sauce or that predecessors can’t fill the same roles (while also using less resources in all directions).
If your free software communications can only be done thru US-based, proprietary options, then you are not free software. To think open source is ideal for your project, but not the tools surrounding it misses the point of trying uplift support & usage of these free sorts of projects (& this isn’t even starting with the privacy & lock-in concerns). Instead of coding around flaws in Microsoft GitHub or building Discord/Slack/Telegram bots, actually build & upstream integrations into the free options as you would like to see folks do unto your own project. Not saying you can’t have these services as an alternative, but as the only option (or the primary option to IIABH) should be shamed & definitely not considered the norm.
Also Matrix is pretty shit, where all the clients/servers run too heavy, & eventual-consistency means self-hosting storage often ballots into ‘too expensive’ which has led to de facto centralization the project cannot fix by design. Meaning Matrix is a better, but still bad chat option.
What would you use besides Matrix?
IRCv3 for accessibility if I need it to be centralized & TLS is the only useful encryption (such as a public chat room); otherwise XMPP + OMEMO for decentralized (but also is great for public chat rooms). No need to reinvent battle-tested, mature standards.
Never thought I’d find another IRC and XMPP fan on lemmy. Let’s replace SSM/MMS/RCS with XMPP while we’re at it.
JMP does that
Yeah I’ve used jmp.chat before, but I couldn’t get any of the clients to work well with my pinephone’s microphone. Shame, since it’s the closest you’re going to get to VoIP on the thing.
What fundemental aspect of Matrix is both causing too heavy performance degradation while also being unfixable or impossible to reimplement?
You could switch some of the problems with perf in switching away from the Python implementation server as well as Element clients but these support the most up-to-date features & the majority of users are now relying on these features that often don’t degrade graacefully.
The bigger issue is eventual consistency. Eventual consistency will not scale for small self-hosting. Every message & every attachment for every user in every chatroom they have joined must be duplicated to your server. This is why joining rooms sometmies takes 10 minutes. Even if you make this async from the client side instead of the current long wait, your server & storage are still taking the hit. A lot of small collectives had to drop their servers for performance & cost (read about yet another one today on the Techlore thread at c/privacy where now only Discord is used for realtime coms). This model is required to copycat the ability to search the entire history like the big, proprietary chat apps such as Slack/Telegram/Discord, but they are centralized so it is easier to manage—but its overuse for all announcement & trying to replace forums turns it into a black hole for information. Your small community probably does not need persistent chat like this—persistent info is lighter & easier to crawl as feeds & forums. With medium-sized servers shutting down, only the biggest & smallest hosts are still kicking with most metadata is largely centralized around Matrix.org who also hosts some of the other larger instances.
If you agree that chat can be chatter as well as ephemeral there is lightweight centralized chat in IRCv3 with TLS has most of the features you need with a longer legacy & massive choice for clients & XMPP for lightweight decentralized chat with a long legacy, client options too, & can be self-hosted in a bedroom on a toaster in comparison which increases the chances of self-hosters & decentralization. These were built in a time when we didn’t have such wasteful taste in tech since they needed to be efficient & only sip power/data in comparison both for clients & servers & storage. The bigger question IMO is what are fundamentally wrong with these two mature options that we need a new option built on unextensible JSON & Israeli Intelligence money?
Well, in their FAQ the Matrix team states that they love both IRC and XMPP and that for those whom these options perform better they wish the best of luck continuing to use them. Matrix does have some qualities they do not and they do not mean to compete with them, rather to put up bridges so as to federate between these decentralized protocols.
Personally, I want to move away from communicating through Discord with many of my friends. I do not believe neither IRC nor XMPP would entice them, but Matrix could as soon as they finish implementing their new video call capabilities. The same goes for community projects that use Discord as a replacement for forums.
Entice how? Spinning up XMPP on any hardware is simple to federate with you—& I wouldn’t wish they all self-host Matrix instances. XMPP’s jingle protocol works for voice/video & I use it self-hosted with my partner. What are the others missing considering the weight of the applications is literally felt. If you want a web client with stickers & reactions (& calling), what is Movim missing? Replacing forums is a part of the problem, not something to replicate… Movim & Libervia cover community posts that are web searchable.
I have no experience with the last two options you mentioned, but I was of the understanding that XMPP does not have video group call functionality. Also, it has been a long time since I used XMPP at all, but syncing history between sessions was not possible to me then. These are features that would be deal breakers to miss.
History / sync is known as message archive management (MAM) & every normal modern client & server supports it. OMEMO uses same double-ratchet encryption & multiple clients as Matrix (with the same old client key dropping issues sadly). By default it does not support groups you are correct, however, FOSS Jitsi (& Zoom for that matter) is powered by XMPP under the hood & can be stood up by yourself.
Personally three of my circles have opted for separate Mumble servers for voice coms (I run one of them from my living room) as video is only ever rarely needed & the system resources is minimal. Having web cams on is seen as a chore & distraction sometimes. The only time video is helpful in my experience is screen share which is different—but screensharing is the worst tool for trying to do code pairing / debugging a terminal using upterm provides a crisper view experience, lower data/system requirements, & observers can optionally drive the remote session.
Did not know about MAM, but that sounds great. I also hosted a Mumble server for my friends for over 5 years, but it was basically never used because there existed a one-stop solution (Discord) that allowed for more stuffTM. TIL Jitsi was powered by XMPP, thanks. I personally have no problem with fragmenting functionality between different specialized applications, but it will always be a tough sell for those I know because they believe they can have it all in their cool app.
At the end of the day, communication services usefulness are upwards limited by the people you can reach through them. The need for everything to be easy and centralized for the user (ironic with respect to server federation, I know) is what has made me so hopeful for the Matrix protocol, since it is designed for allowing this while still being decentralized at its core.
One of my longer-term goals is to integrate Mumble on XMPP (others have thought about this too) since its chat is pretty shit & needing accounts to join isn’t great but or two good foundational protocols.
XMPP is better for modularity which is why everything is at extension with means the foundations are simple & easy to implement where you can build something optimized & bespoke on it like Fornite’s coms or Nintendo’s presense. It’s a little harder to understand tho since out of the box you get almost nothing—but the big servers intended for chat like Prosody & ejabberd have sane defaults.
The centralization you are referring to seems more a client issue since the protocol & servers already ‘do the things’ but it sounds like you want a single ‘app’. For community building where you consider group calls less common, both Movim & Libervia offer more than Element (note the other Matrix clients are lacking feature parity) since they both can do integrated posts like forums—where Libervia supports calendars/events too. There’s no reason a client couldn’t exist with Jitsi or Mumble integration.
Ultimately use the right tool for you—it’s just nice to dispel myths that Matrix has some special sauce or that predecessors can’t fill the same roles (while also using less resources in all directions).