Update on Registration Requirement to Utilize Push Gateway

For using the push gateway and the internal apps marketplace.

@gabriel.engel Since RC is a web application couldn’t the Google/Apple push notification API and the need for your AWS gateway be eliminated by using websockets (e.g. socketcluster)?

I envisage the mobile application could start a background service which connects/disconnects when a user is logged into/out of any RC server.

Such a solution like this has been looked at many times. The problem with these sort of solutions are endless. The only platform its likely to really work for is Android. iOS for example now kills off background connections pretty aggressively.

I suspect even Android in some cases does.

Not to mention when you move to keeping your own socket open… battery becomes a big concern.

Personally would love it if a project like ownpush would come along stabilize and be a good alternative for both platforms.

The short of it… Much, much easier said than done. :frowning_face:

1 Like

Hi,

I’ve been looking at this thread as my RC instance was reminding me to sort this out.

Would it be correct that not registering would eventually be the same as setting “Enable” or “Enable Gateway” in admin/Push to disabled?

What is the difference between those two anyway? Are there push features which don’t use the gateway?

Re: the 5k limit. Will it be possible to simply stop the notifications on hitting the limit rather than incurring charges?

Thanks,
Phil.

1 Like

Only mobile app notifications use the push gateway.

I’m curious about this too.
I looked for the documentation but couldn’t find…

1 Like

@aaron.ogle I’ve now looked into firebase cloud messaging, FCM, and I cannot see why the existing mobile apps cannot register for message notification from multiple servers without needing your AWS gateway. There is also no need to expose the secret key from your own FCM account.

My understanding is that each RC web host can open a FCM account (which is free) and create their own RocketChat project, so that they obtain a SENDER_ID and API_KEY for their server/domain. Both keys can be provided to the RocketChat server application at runtime via environment variables.

Then the Android/ios apps can connect to multiple servers by requesting a SENDER_ID, when they login (possibly via a secure websocket), fetch the corresponding FCM registration token and share it with the server.
https://firebase.google.com/docs/cloud-messaging/concept-options#receiving-messages-from-multiple-senders
A node.js server can multicast messages to a maximum of 500 token IDs per send invocation.
https://firebase.google.com/docs/cloud-messaging/send-message

1 Like

What if someone buys a 10k push and exceeds this number in a month?

Push will be automatically turned off or will you charge additional fees in some way?

Can I buy 5 packs of 10k push?
I learned from another source that it will not be possible and the only option is to buy the enterprise version.

1 Like

No response? @gabriel.engel

Can anyone explain why adding a handshake to the RC server and mobile apps for exchanging the sender_id and client token isn’t feasible?

Where can I find it?

There is a problem with server registration.


Anybody can help with it?

No plans to have an “auto charge” based on usage. We’d make communication before you hit it and if you chose to you could increase the cap. Details about how that all will work will come before the cap goes in place along with the way to view usage.

We had this same line of thoughts when we originally did all of this. I believe with APN this was not a possibility… This was before FCM and FCM sending to iOS. No clue how that actually works if they sit in front of APN or how they get messages there.

Also our client is multi-workspace ready… (I have 5 different workspaces on my mobile device) and I think one could not register multiple times to FCM/APN with multiple FCM/APN accounts per device…

@aaron.ogle Thanks for the reply. By multi-workspace do you mean concurrent logins to multiple RC servers?

Looking at the links I posted, my understanding is that a single mobile app can certainly register for push notification from multiple different FCM accounts by first obtaining the SENDER_ID from the RC server, obtaining an associated token and then handing it back, so that the web server can append it to a list. This is where I think a websocket handshake would be needed in both the client apps and RC server. Doing this at runtime differs from the simple examples of embedding FCM account tokens in a mobile app at build time.

Right.

I’ll bring your messages up to mobile team to look at. I know they’ve gone to a lot of work to provide instructions on how to compile own apps embedding your own token and now hard at work on some very exciting features. Maybe this is something they can do in the future.

@aaron.ogle Thanks.

Given the number of people fretting about push notification costs or threatening to leave RC, I would think many would be willing to contribute towards a bounty to make this a priority feature.

Our favorite kind of contributions are pull requests. If people raise bounty and a contributor wanted to implement and collect that works too :slight_smile:

1 Like

What if someone buys a 10k push and exceeds this number in a month?

Push will be automatically turned off or will you charge additional fees in some way?

Can I buy 5 packs of 10k push?
I learned from another source that it will not be possible and the only option is to buy the enterprise version.

@aaron.ogle could you help me?

In case you bought a 10k extra, once you pass the 11k (1k free + 10k) your push will stop until the end of the month period. You will be able to track that usage and receive alerts about reaching the limits.

It’s not possible to buy the same package multiple times, so you can’t buy 5 packs of 10k, but you can by the 10k and the 5k ending with 16k. We will keep monitoring the usage and your feedbacks, we may add other packages in the future, you can always contact our sales team (sales@rocket.chat) in order to negotiate or check if you can fit in our list of supported organizations and receive a higher limit.

After installing and configuring Matrix I did found Matrix is great and very very cool, and definitively its client, Element, is years ahead from RocketChat, its integrations are awesome and in general, is awesome in all the aspects, but… I’ve discarded it because is not an enterprise-grade chat: no AD integration (I had to set up an OpenLDAP to act as AD proxy), any user can create a channel and they become administrators of that channel, so even the global administrator cannot access, control or even remove those channels… Matrix is great as the 21th century IRC, but not as an enterprise chat.

There is a cool alternative to RC called Zulip. Its client is a bit different as is designed to “fork” general conversations into “streams” so people cannot make noise in the parent chat, but this can be a bit confusing at first. I like more the interface of Zulip (well, I think RC has the worst GUI out there!), and push notifications, besides to be free, works as they should. Zulips has also all the enterprise features one system administrator can expect from an enterprise chat, and far more integrations than RC.

I’m testing it with the IT Team and I’m quite happy with the change, yet I’m a bit afraid for my users to get to the streams feature.

I saw no way to export RC chats to matrix, mattermost, zulip or whatsoever… if you do the change, you’ll lose all the conversations. There are bridges to one chat system to another, but those bridges doesn’t “import” old messages.