Address notifications logic and UX inconsistencies

There are some issues with the way notifications are handled in Rocket.Chat that cause confusion for both developers and users.

Below I’ve outlined each concern, but I’d like comment and direction from @RocketChat/core team, to find a comprehensive solution and give clarity to these features moving forward.

Thanks to @graywolf336 for writing up the first section on Rocket.Cat…

Who or What Is Rocket.Cat?!

Ah the age old question for current developers and the confusing question for new developers interacting with Rocket.Chat. Rocket.Cat currently exists in the code base of Rocket.Chat as a user that is always there. The reason this happens is that throughout the code base of Rocket.Chat we have always needed a user to exist for various reasons, whether that any or all of the following:

• When a user is deleted but the setting Message_ErasureType is set to Unlink and all messages of the deleted user are thus assigned to Rocket.Cat * For messages coming over via the SlackBridge
• For Ephemeral messages which are notifications or not required messages
• Default user for the messages coming from integrations (incoming and outgoing)
• Is the default user for the Internal Hubot

However, there has been mass confusion over this for developers of all kind, and especially users, who don't have the time to investigate what exactly the Rocket.Cat user is. For example, a user might think that the Rocket.Cat user belongs to the Internal Hubot and expect that when they disable the Internal Hubot the messages from the Rocket.Cat user will go away. Yet that's not the case and thus is very confusing to have disabled the Internal Hubot but still get messages from the Rocket.Cat user when you try to send a message in a channel you're muted in.

So, I think we need a distinction in docs (possibly assisted by semantic helper methods) as to where and why Rocket.Cat should be used. Which I think should be only as the fallback default “system” user:

• It can continue to send messages from integrations (like Slack bridge)
• Maybe it can be used by some core methods to send notifications with good reason
• It should not be used for internal Hubot or any instance specific messaging
• If it cannot be disabled for notifications, the option to “disable” the user should be removed

Stream notifications VS alerts

There’s currently four different visual feedback components in the UI.

• Top bar alerts, for version updates and server issues, restarting etc.
• Modal displays, for confirmations and warnings, such as on hiding a room.
• Notifications and alerts via “toastr” package, e.g. save profile errors.
• Stream notifications, such as “you have been muted”, inline with messages.

There is no obvious hierarchy for developers to know how to use these tools and make contributions that don’t just further complicate the experience for users.

They are all visually different and do not communicate any sense of differing priority in the notifications - for lack a better term, it all just feels kinda random.

I think at least one of these approaches should be dropped. I would prefer it was the stream notifications...

Why use stream notifications?

Currently, the approach of creating stream notifications as pseudo messages is adding to the confusion.

• They come from the same user that could send actual messages
• Some of these messages don’t persist in the channel (are only temporarily in the client)
• The author can’t be replied to, unless it’s in use as a bot
• It’s not the bot that sent the notification, the bot is effectively being impersonated, so it’s not aware of all messages generated in it’s name
• There’s no reason to have a distinct identity for the source of the notification, it could just be a system dialog
• The identity is just one more thing for instance owners to manage and easy to misunderstand how it will manifest

Bot notifications

Custom instance specific apps and bots might need to send notifications too.

They should be distinct from the system notifications, they could even just be a normal message with some special formatting. Any solution to the general issues should consider how a bot and a system notification are different, in code and design.

Mobile...

I have no idea how these issues relate across the mobile apps?

This discussion can close related issues (#3869, #4016, #4103) to keep all in one place.

Pinging for comment @engelgabriel @Sing-Li @rodrigok @graywolf336 @karlprieb @rafaelks

Start with server/startup/initialData.js to understand the Rocket.Cat user, then review the four notification paths described in the issue, including toastr and stream notifications. Check related issues #3869, #4016, and #4103; this issue is done only when the team agrees on a clear system-versus-bot notification model and its UI, mobile, and documentation implications.