🆕 Software Suggestion | Rocket.chat

[zlbabe]

Basic Information

Name: Rocket.chat
Category: software
URL: https://rocket.chat/
Github: https://github.com/RocketChat

Description

The ultimate Free Open Source Solution for team communications.

[danarel]

I second Rocket.Chat

Good software that can be self-hosted. Great alternative to Slack.

[zlbabe]

I still don't know why people keep using slack, that's mad !!

[danarel]

It's not really a chat app like SIgnal, so the contacts you're moving there are work ones. It's a replacement for Slack. So it's good for team collaboration chats.

[jonaharagon]

I agree this would probably require a new category if it were added, like "Team Collaboration". Not the best fit for general Instant Messaging.

[danarel]

Maybe under productivity tools?

[jonaharagon]

Perhaps, although I feel like if we wanted to do alternatives to Slack, Mattermost, Google Hangouts for Business, etc., there might be enough alternatives to warrant a separate category?

• Rocket.Chat of course
• Zulip
• Riot.im is kind of in a gray area between IM and this but could be listed twice
• Mattermost?

...maybe there aren't as many as I thought but that's just off the top of my head. Or I suppose these could be added to Productivity under a Real-Time Chat header or something, whatever works.

[blacklight447]

I would say that we should make a new category.

[five-c-d]

Please not three categories. We already have IM category and VoIP category, with most of the tools in both areas doing something that can be categorized as "voice-chat or at least voice-notes" and pretty much ALL of the tools handling basic IM-type-stuff.

If we add a third category for "productivity-chat" that is going to make things more difficult, not less. RocketChat is aimed at teams, just like WirePro and RiotIM and whatsapp4biz, but you can use signalapp for groupchats as well (in a corporate environment where the firm provides all employees with BoringPhones or work phones or whatever).

It is a distinction, but it is a distinction in how things are used (and what they are optimized for), not one that is a tool-category-distinction methinks. The category is "messengers" and the subcategories are

1. "IM" aka 1-on-1 chat
2. "teams" aka groupchat / "productivity-chat"
3. "VoIP" aka quasi-realtime-audio&video chat (though voiceNotes are a fallback)
4. "confcalls" aka N-way quasi-realtime-audio&video chat

There is a separate category for file-transfer tools, because although you can transfer files with messengers, it is not optimal (and there are usually strict size-caps). You are better off transferring a large file using a dedicated tool like firefoxSend or magicWormhole, and then using your messenger-app to send the URL of that file-transfer.

If there have to be two categories, I would suggest one of them be "one-on-one messengers" that encompasses IM+VoIP between two humans (each having multiple devices that sync together). The other category would be "N-way messengers" which would cover groupchats and confcalls. Almost every one-on-one messenger can do some kind of voice-chat, and some kind of groupchat, but it is rare to see N-way end2end encrypted video-confcalls.

[Mikaela]

Sorry @five-c-d, #1065

Warning to Rocket.chat: End-to-end encryption is currently in alpha and not supported on mobile.

[five-c-d]

RocketChat stores the quasi-end2end keys, server-side. And does not implement perfect forward secrecy. More like protonmail's security-model than like signalapp. RocketChat/Rocket.Chat#9999 (comment) Basically, if your decrypt-passphrase is every compromised (either by a trojan or a compromised server... or just, by you logging in from a browser or OS that is vulnerable to the badguys) then the badguys get your entire messaging-history, and that of every team you are on, correct?

[Perelandra0x309]

I could not find any detailed technical documents on their website so I went looking at the code. Here is where the key generation happens:
https://github.com/RocketChat/Rocket.Chat/blob/develop/app/e2e/client/helper.js

The generateAESKey function creates a AES-CBC 128 bit key to use for encrypting the message data. The generateRSAKey creates an RSA 2048 bit key that is used for a user's public/private key. Essentially what happens is the message gets encrypted with a AES key, then that AES key is encrypted for all participants in a room with their public RSA key.

I have concerns that these keys are not very strong by today's computing standards and probably will not be considered safe within 10 years. With the open source options we have today with elliptical curve shared secret generation, perfect forward secrecy and ratcheting keys using these older encryption methods is disappointing and potentially dangerous.