As if the world needs yet another slack-like.
xkcd_15_competing_standards.png
Making a project just to learn is par per course. Chat… especially non federated chat isn’t really that hard to implement as a protocol. It’s the UX that’s hard to nail down, and if they can get it right it won’t matter if Matrix existed first.
When I hear discord I generally think of voice/video chat and screen sharing, and less about text chat; this may be a side effect of all the bridges, though, as I tend to chat on IRC and all three of my primary discord channels are bridged.
I run matrix, mattermost, and rocket.chat. I like the api/whatever of mattermost but I really like the overall feel of matrix the best.
Matrix also has nothing to do with UI or UX. The clients do. Write a new client if all you care about is UI/UX. You have a much higher chance of success.
Mumble/Murmur and Teamspeak have better voice functionality than Discord, because they really are designed for voice chatting.
> But not in text (Mumble severely lacking, Teamspeak marginally better).
Concur, and this, along with all-in-one Slack-like rich URL handling leads to selections of discord.
A more OSS friendly stack of Pidgin + Daemon | IRC & Mumble/Murmur seems to have the best scaling, and the best of both worlds, at least in my opinion because it has the lowest cost, richest functionality, and can scale the highest in terms of users without being dependent on a commercial service. I say this because I have seen Mumble/Murmur with > 2000 active users which is possible due to the rich permissioning system and excellent performance.
You mean another IRC-like? :)
As much as we can all agree that IRC-likes, and even IRC's predecessors are wonderful and responsible for much of the progress we have today, I think we can also fairly say not every chat application from now unto forever is an IRC-like.
I would (and I think fairly) catagorise a set of slack-likes and IRC-likes differently, with matrix occupying a grey area inbetween.
Sometimes it's worthwhile to consider that the "third party rules" you don't want to abide, are there for good reason.
Furthermore, sometimes the underlying reason for those rules is something you can hack on and open up.
"Oh we won't ever support feature X because of legacy arch Y so no PRs for feature X please". Well, perhaps you can solve legacy arch Y and help everyone at a more fundamental level.
> Matrix is incredibly buggy at times and it’s left a sour taste in my mouth.
Speaking as project lead for Matrix... I can see where this is coming from. Were we doing Matrix from scratch again, we'd have a smaller scope and polish each feature more before releasing and moving onto the next thing. However, we're very aware of this, and these days do almost nothing else other than polishing the current codebase - for instance, Synapse's RAM usage has dropped enormously (https://twitter.com/matrixdotorg/status/1434912387933560837) - all the main serverside bottlenecks have been removed; we're working on speeding up joins enormously; Element's performance is improving massively; we're working a complete rethink of the client-server sync protocol to ensure that only the bare minimum data is ever synced to clients by default. The only new feature work we have on the horizon is exiting Spaces (groups of rooms) from beta, and adding Threading. Otherwise, it's "just" a matter of fixing remaining E2EE bugs; reworking E2EE onboarding UX, and lots and lots of polish.
Critically, *NONE* of these bugs are due to federation or decentralisation. Ironically, the federation bit of Matrix is one of the most robust bits these days - after we spent ages polishing it in 2018-2019 to fix bugs in the merge resolution code. So I think the...
> Federation and Discord-style protocols are inherently incompatible
...assertion in the revolt FAQ is completely false, and Matrix already disproves it. Residual bugs in Matrix implementations are more thanks to the complexity of federation/decentralisation/encryption sucking a lot of energy away from the more business-as-usual things which you'd focus on if building a Revolt/Rocket/Mattermost style thing.
Anyway: Revolt looks cool, and we wish them the best, and hope that they will indeed bridge into Matrix in future, which is honestly quite a good compromise - https://matrix.org/blog/2020/12/07/gitter-now-speaks-matrix#... is the guide to follow to rapidly plug an existing chat system into Matrix, much as we did with Gitter :)
Keep polishing it and silence the haters
Seriously, for anyone else reading, this attempt to provide federated privacy of communication is the kind of thing Saint iGNUcious himself might bless (I don't know if he does but am hopeful).
I had a chat with a friend recently and he said in response to my declination to use Signal:
"(I appreciate the commitment to decentralisation, but the battle of messaging apps ended up elsewhere). You're still fighting for the emperor in the jungle but the forces in the war changed years ago :)"
Decentralisation is the very purpose of the Internet, and federation is how it will work.
We just need to help you solve all the user experience problems, and they are very soluble.
Keep up the great work!
Really? I wonder how Rocket.Chat federation overcame this "inherent incompatibility"
https://docs.rocket.chat/guides/administration/administratio...
Most of their features is just PR. For example they do advertise E2E while it has the same amount of warnings and not even a doc page https://docs.rocket.chat/guides/administration/administratio...
Matrix is the practical solution, and Arathorn's sibling comment gracefully addressed my real criticism. Federation is absolutely possible on these applications, although tricky.
Well, yes, it is honest, but it also is disturbing - which other well-known network principles were unknown to them?
[0] Most likely this is referencing the term and the structural pattern; as you correctly pointed out, the concept is quite widespread.