Our open source platform has come a long way since the start of our journey in 2015. With usage numbers now in the millions, we are facing increasing operational costs. We have discussed ways to soften the load this causes on our resources, while at the same time ensuring that the service we provide remains fully available to the community at the same high standard we always strive to maintain.
Therefore, in order to mitigate some of these costs, we have decided to make a small adjustment to the way our push notification service is offered at higher volumes.
The basis for this decision was a comprehensive statistical analysis performed on our push notification dataset. We have found that the notification volume tends to follow a Pareto distribution. This means that roughly 20% of the installed base is responsible for 80% of the push notification usage. On the flip side, 80% of the base reports fewer than 1000 notifications per month.
In the next few weeks, we will start offering a dedicated push notification package for customers who use over 1000 monthly push notifications. We believe that we are offering convenience and good value in exchange for a fair price, with the ultimate goal of ensuring that Rocket.Chat remains available and operational for the community at large.
Instances using fewer than 1000 monthly push notifications will not be charged. Additionally, anyone who wishes to have full control over the push notification services can host their own servers and integrate with the Apple and Google networks without purchasing the package, as was already the case.
There needs to be some clarification on the rate limits because that can make a huge difference.
There are probably a lot of wasted notifications. If I am at my desk and have autoaway set, but donât have focus on the Rocket, I can get notifications to my phone because I havenât checked the desktop app for a while, which are unnecessary. Multiply that by several users and you can get a lot of notifications that are not needed. I am not sure of the answer to this, but it is an avenue to look at.
Yes it is possible to set up your own notification service, but the bar to doing this is pretty high. You need to buy in to the Google eco system for starters. And then a iOS dev account, and presumably have to roll your own apps. The irony for that is the high volume users you are targeting probably have the time and resources to do it themselves, and when faced with the new costs may decide it is more cost effective to do so, thereby losing you the very market you are aiming at. What happens then? Reduce the limit further to try and balance the revenue/costs?
I also note that the Documentation talks about the Cordova app, which is now deprecated, and there is nothing on the React/Kotlin versions?
I fully appreciate the position that Rocket is in, but Iâm not sure this will have the outcome you are after.
If the community can help to minimize the costs for Rocket.Chat, it would be useful to write a good manual for the operation of your own âPush Gatewayâ and what the procedures at Google and Apple are like. As @reetp mentioned, there are certainly many operators of larger installations who can do this. This could reduce the volume on gateway.rocket.chat considerably and Rocket.Chat could not take over any costs for third parties.
This brings me to the question of how high the costs are now?
Per workspace (or server) this will be grouped based on the registration not based on DNS to avoid any sort of duplicates counting towards.
Actually updating the doc now to hopefully make this a bit more clear: Push
But if you run your own gateway you will have to run your own apps.
It all boils down to having to compile creds into the actual app to work with GCM / APN.
Yeah this is definitely a possible scenario. One that I run into from time to time. Though with desktop application not so often as the idle detector seems to do a pretty good job of detecting when truly idle vs just not in focus.
Our aim definitely isnât to isolate anyone. We have no plans of rushing into this and cutting off anyoneâs push notification access. This will be a soft cap at first. We will be evaluating closely.
Reference has been removed for cordova in the refactor of the doc.
Will there be a documentation for pricing of push notifications?
For now I believe: 100 people are in one channel, so while there is a single message pushed, it counts for 100 push messages.
How will accounting be organised? We run four servers listening on different domains (multi tenant (teams) feature would be great), but still we are one company. Can we register four servers in one account and will have 1.000 messages for each instance?
Soft cap sounds great, is this thread the right channel -to keep an eye on- for news on this?
At the moment, we are organizing them by âworkspaceâ and each individual server that runs on a different domain (can be a little more complicated than this) will have their own limit of one thousand push notifications. This is as is, but we will let everyone know should it change.
As always itâs super easy to say something like that. But much harder to do. ;-). We are always open to pull requests for features like this. So if you or someone else wants to take a crack at this please do!
There is always also the option to compile your own apps if you want to instead use your own creds from Google and Apple. The code for all of our apps are also open source. A few others have gone this route.
Important to reiterate though. This limit is not yet being enforced.
Is there a reason the gateway keys for private servers have to be compiled into the app? Wouldnât it be possible to make the client pull them from the server when it first joins and then store them locally for future use?
