New Matrix Alternative #49
Labels
No Label
Breaking
Domain
komu.boo
Domain
langrock.info
Domain
libre.moe
Involves
Documentation
Involves
Security
Involves
Testing
Kind
Bug
Kind
Enhancement
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Service
Drone
Service
Element
Service
Gitea
Service
Matrix
Service
Nextcloud
Service
Szuru
Status
Abandoned
Status
Acknowledged
Status
Blocked
Status
Duplicate
Status
Invalid
Status
Need More Info
Status
Won't Fix
No Milestone
No project
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: KomuSolutions/igot99issues#49
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The Why
We are using Matrix currently for our chatting needs, because it supports all features we want, but it (and especially the Element client) is very buggy. So we would like to look for more stable alternatives.
The What
Our requirements, in descending order of importance.
Please comment below, if you think something is missing or in the wrong order.
The Which
https://github.com/awesome-selfhosted/awesome-selfhosted?tab=readme-ov-file#communication---custom-communication-systems
Smaller list of more relevant candidates following soon.
The Where
komu.boo or libre.moe?
Why not do a race after settling on which service we would like to run ;)
The Wo-Dos
I am actually already preparing a test instance of Zulip, which generally seems to support most of our needs, but most importantly has a clear and easy to navigate UI, allowing specific rooms to habe a static listing (like in discord servers), unlike the Chat-style of Matrix/Element.
Zulip has a strong enterprise user base and is very self-hosting/open-source friendly. It seems to lack E2EE, but I personally don't view this as a problem for "public" rooms for memes, university chats, gaming and so on. And using Signal for personal and more private stuff isn't so bad either.
You can see Zulip in use here.
When you compare team-chat platforms like Zulip, it quickly becomes obvious that Zulip is the most appropriate for us, this is what I found out about the free oss tiers of different platforms:
As "Communities and personal organizations (clubs, groups of friends, volunteer groups, etc.)" qualify for the community plan, we could also get unlimited mobile notifications with Zulip for free.
Unfortunately, Zulip's docker image is experimental and the main app's image has no ARM-builds, even though arm is officially supported. I guess right now, a native installation is the best option (sadly).
Otherwise, Mattermost is also looking good UI wise, probably even better than Zulip, but I don't really consider it as it lacks SSO. There is a hack using GitLab and redirecting to your own SSO through GitLab, but let's not do that :)
The UI looks a lot like Discord - which is awesome. It also supports S3 for storage ^^
dev instance is up on https://dev.libre.moe
Opinions?
Several
care to share?
In regards to #49 (comment), I actually wouldn't count all of these as requirements and would like to structure this a bit different:
In order to fit our architecture, the solution should be:
and ideally should also have:
In order to fit our use case, the solution should provide:
Additionally, nice to have features are:
arm64archMost notably, I view E2EE and Federation as optional, as this is primarily used as a community hub and chatroom with additional direct messaging, at least that is how I see it. While a use case as both primary personal chat and community hub is nice, Signal is always a great fallback for personal chats.
I am quite hesitant to recommend E2EE for larger/public spaces, as having chat history for new users and no issues with encryption keys / signing for non-technical users is far more important than cryptography for our anime waifus and memes.
I also changed the architectural requirements/recommendations to reflect my setup and liking.
Numbered requirements reflect the order of importance, while non-numbered requirements should all be met.
Here is a quick technical review of Zulip, based on hosting this dev instance:
I also will look into Revolt, as it looks similar to Discord in both UI and feature set, therefore it should also meet a lot of our requirements.
I'll also throw another different kind of concept into the ring: XMPP-based solutions.
Those fit really well with our ideology and are quite extensible with a vast ecosystem and tooling available.
While most clients are quite legacy in their design, I found Movim, which at first glance looks promising.
@leon This issue was created by you with
Prioritiy High, but there has been more than a month of inactivity, should we change the priority?No