Perhaps it is time to think about alternatives
-
@marcusquinn Marcus, I noticed your crowing about NextCloud talk higher in the thread. It caught my eye. My own experience with NextCloud file sharing and address sync has been painful enough over the course of years (partly Apple's fault) that I'm not keen to rely more on NextCloud. It's been a high maintenance slog. Probably for hundreds of users it's worth it but certainly not for half a dozen users.
To be honest, until relatively recently our RocketChat experience has been much better. We were early users and really loved this app, it's just become so community unfriendly.
@LoudLemur I'll take a look at Zulip. Thanks for the suggestion.
-
@girish Yes mainly. It just seemed too complicated for me to sign off as GDPR compliant for our org.
Some or all of these criticisms may be valid
https://github.com/libremonde-org/paper-research-privacy-matrix.org/blob/master/part2/README.mdOr maybe not, I didn't have the time or inclination to work it out and just went with Mattermost instead
-
@Sam_uk We looked at Mattermost at the time we first considered RocketChat, many years ago. There were some issues then (about five years ago). What are the limitations of Mattermost in 2023?
-
For anyone who is reading along, Zulip pricing (
if one decides to host with them and not on Cloudron– oops there is no Cloudron version) is per user at about $7/month. We strongly dislike per user pricing (even if it would often be in our favour these days) as it discourages employing people part-time or giving the full team access to tools. We are not looking for another package to manage ourselves (we do manage our own FreeScout and use it intensively enough to make doing so worthwhile, plus it gets FreeScout on the our .com domain rather than the .org) so we are really looking at what chat applications is in the Cloudron repository.- RocketChat is great but gradually squeezing out open source and has privacy issues.
- Mastodon is overkill (we're not trying to build an international open communication platform or federate)
- Matrix seems too complicated
- TeamSpeak seems intriguing but more focused on VOIP than we need
- Element could work but we are unfamiliar with it
- The Lounge – IRC (we happily used vanilla XMPP for years) seems like a step backwards (poor file handling) but is a barebones option which could suit us
- Mattermost – the category of application for which we are looking, lost out the sweepstakes to RocketChat years ago as perhaps Mattermost was not on Cloudron back then and there were some severe limitations to the open source version.
This post is not advocating for Zulip or adding yet more chat applications to the already overburdened Cloudron team. It's just exploring what the best option might be out of what is there already. Element looks a lot like RocketChat/Zulip. Does anybody out there have feedback on how it is to run Element on Cloudron and/or in production?
We'd be giving up the option of livechat on our website but the RocketChat livechat is not great and we're not using it much this year. (RocketChat calls live chat Omnichannel).
-
https://forum.cloudron.io/topic/1220/zulip-powerful-open-source-group-chat?_=1702033809412
On Cloudron, one would install matrix as the server and then element as a client which users could interface with using their web-browser. There is also an option to download a desktop element client. Element might be a bit complex looking to those less familiar with computers.
I hope that Cloudron supports XMPP by offering ejabberd.
https://forum.cloudron.io/topic/2486/ejabberd-robust-scalable-and-extensible-realtime-server-using-xmpp-mqtt-and-sip?_=1702033809416 -
Thanks for the info @LoudLemur. You said in Perhaps it is time to think about alternatives:
On Cloudron, one would install matrix as the server and then element as a client which users could interface with using their web-browser.
There's nothing on the Cloudron Element info page to indicate dependency on an external Matrix server. It looks like Element would run freestanding. If this is not the case, the Cloudron info page for Element should probably show that dependency.
-
Element isn't a dependency, but is one of the front-end options for matrix, and Cloudron supports it.
The cloudron documentation links to this page:
https://matrix.org/ecosystem/clients/ -
-
@LoudLemur said in Perhaps it is time to think about alternatives:
Element isn't a dependency
You have reversed what I asked. My question is whether Matrix is a dependency for Element. I.e. is Element self-sufficient or does it require a Matrix server (which we probably don't need). I am against additional levels of complexity. Commercial software these days (even and especially the OS underneath) are ridiculously overcomplicated and open source is slowly following in its footsteps down what looks like the wrong path. I'm looking for simplicity in our chat application. Ideally it would be written in PHP/JS/CSS so we could improve it where we find rough edges.
-
@foliovision said in Perhaps it is time to think about alternatives:
is Element self-sufficient or does it require a Matrix server
It requires a Matrix server. Not necessarily your own though. Presumably you could use it to log into any Matrix account. But it's not a standalone thing. It's a Matrix client.
-
Without prior notice (?) I have noticed that one of my rocket.chat instances is in a
Pro trialstatus.
If you log in as an administrator and go to the workspace/subscription page (https://chat.example.org/admin/subscription), there is a link to
Contact sales to finish your purchase and avoid downgrade consequences.https://docs.rocket.chat/resources/frequently-asked-questions/license-faqs/downgrade-behaviorI have no problem with FLOSS communities looking for ways to raise money. But that feels wrong. On so many levels.
Thank you for 49 replies to my first post from mid-2022.
In a more general way: What is a chat? Which 'problem' should be solved by a chat tool?
For me, chat is fluid. There is no need for permanent information. It's more of a tool that replaces a thread full of nonsensical emails. Fire and forget. And I have no problem with all messages being automatically deleted after (say) 30 days.
For some of my teammates, it's a repository for information. They try to find the right thread in the chat where they discussed something without transferring the result of the discussion to other tools like an issue in Git or a wiki page. But the internal search in rocket.chat is far from being useful.
Others complained about rocket.chat because they were never informed about new messages on their smartphone.
I'll add these wishes to a short list. What should a "perfect" chat do (besides standards like groups, threads, channels, bla ...)?
- (reliable) Notifications on a mobile device
- a "smart" search
Should we see a chat tool as something like a messenger? Or an alternative to e-mail? Perhaps as a replacement for the telephone?
-
@luckow said in Perhaps it is time to think about alternatives:
Should we see a chat tool as something like a messenger? Or an alternative to e-mail? Perhaps as a replacement for the telephone?
That's the way it'll end up whether intentional or not. You have 1000's of different ways/apps to communicate now. Each app wants to stand out somehow. Solution? Offer a feature no-one else has. Chatwoot (a live chat app) has built-in email capability. Beeper (latest hot app) offers a ton of bridges to merge all these chats. Everyone is running to "federate" things. We had the telephone, one system, all "federated". I can call anyone in the world, but it was too centralized, too controlled, so we embraced tech and the plethora of "secure" apps (signal, matrix, etc.). Now, we're trying to federate all those apps again. The real question is, WHY? It's simple, the human mind will create problems when there are none. We get bored and probably will go insane if we have no problems in our lives.
-
@humptydumpty Kinda how the free-market works. Failures are features of progress. The challenge of monetisation to fund sufficient developers to make the perfect apps is likely the biggest bottleneck to progress.
-
I recently found https://fluffychat.im/ which is another matrix frontend with a focus on personal messaging. It works rather well for the short development timeframe. It is kinda very nice to be able to plug all those different frontends to matrix. Without good alternative frontend it will always feel a bit strange to have the synapse matrix server decoupled from element.
-
Personally I'm not a fan of the Matrix conception.
- set up a Matrix server.
- now set up a front end for it.
It's very extra admin-y for what is already enough of a headache. Would like something simple, like RocketChat looked to be four or five years ago before federation, problems with push notifications, Omnichat (we did use the livechat feature for awhile, it didn't work all that smoothly we probably would have been better served to use a dedicated livechat app).
Sad to hear RocketChat is more or less end of line (the 20 users or less restriction has turned official RocketChat into demoware).
-
@foliovision said in Perhaps it is time to think about alternatives:
Sad to hear RocketChat is more or less end of line (the 20 users or less restriction has turned official RocketChat into demoware).
My understanding is that with Rocket.Chat CE there is no limitation per this thread - https://github.com/RocketChat/Rocket.Chat/issues/31149 . To get to "CE" you have to jump a bunch of hoops though per the comments in the issue.
-
The automatic enrollment of all upgraded servers (including auto-updated) into the starter enterprise subscription with a limit of 25 users was a bad decision, not thought out at all.
Almost all users of open source, and Rocket.chat in particular, are especially sensitive about privacy and consent.
Anyway, the Community Edition users won't have the user number limitation, which is now clear. Phew.
As for chat clients, we had Rocketchat with Omnichannel some time ago but abandoned it.
Since our students were already on Discord, We moved to Discord as well. The interface takes some time to get used to though.
