Final Update on Registration Requirement to Utilize Push Gateway

So here’s the thing with this @sing.li, in your quote above you are obfuscating very specific issues by generalizing them under the blanket of “your specific preference” and “will continue to evolve the solution” as though there are a lot of different issues related to regulating the number of push notifications and that they are all of equal importance and being methodically addressed over time.

That might all make sense under a scenario where you are NOT CHARGING PEOPLE for sending push notifications.

Under the scenario that begins on November 16, where you ARE CHARGING PEOPLE for sending push notifications, there are a couple of very specific requirements that I and others in this thread have mentioned that seem like hard requirements to implement and fully test BEFORE you start charging people and/or cutting off their server’s ability to send push notifications.

To recap, these are:

  1. RC should not be sending mobile push notifications for messages that have already been marked as read / seen via web or desktop app. This is a bug that could result in you either cutting people’s push notifications off or charging them for more monthly notifications than they would otherwise need. Fix the bug before implementing the cutoff.

  2. There are users who may have set their default notification preferences in RC to send mobile notifications for everything everywhere and then may be managing those notifications at the device level. Or just ignoring notifications they don’t really need. RC admins need to have the ability to override the notification preferences of users on their server. Again, this inability to modify these preferences could cause people to use many more push notifications than they need, so you should fix this before implementing the cutoff.

Not making these changes (so that admins continue not to be able to really control the number of push notifications their servers are using) before implementing the cutoff is an ethically poor choice.

8 Likes

@RPQ @Andreas @TheUpsideDown
I suggested a solution but the RC team won’t publish the notification key from their Apple developer account. It’s not needed for Android push notification.

It could still be done with an independent Apple developer account, but someone would have to then take responsibility for building the new releases and uploading them to the Google/Apple app stores.

Otherwise I suggest you look at Zulip.

1 Like

This is already in the works. Please send an email to this temporary email address so I can get you in touch with that person: leney37874 [at] jah8 [dot] com

@RPQ I sent an email but go no response.

I never received anything. You must have made a mistake. Try this one: chequita [at] jescanned [dot] com

Remember, it’s a temporary email, so if you respond a day or two later then I won’t receive it.

Hey guys,

we’re going to get hit hard by the push limit, and I’m not certain why. I’m suspecting a bug that sends push notifications twice, and made a post about it here -> Push notifications sent twice?! - maybe I could get some help?

We’re a nonprofit community with about 50 active users, and hitting 16000 push notifications with what I think is light to medium usage. The official recommendation for the basic edition is 300 users, which we’re way below.

  • we don’t have bots that spam channels
  • we only have 2 broadcast channels with medium use

On the other hand… having “General Chat” with 50 users in it will only allow you 300 messages until you hit the global 15k limit for your whole instance.

I mean… 300 messages. In an instant messenger. Most of us have been in IRC channels where this amount is sent within an hour, not a month.

This forum is a place where you can conduct debates on any topic without any results. Better open the GitHub, there may be someone wrote something on your topic.

well, they just dont give a fuck… and they wouldnt on github either

1 Like

@Andreas On GitHub, there is a chance that there is a person with the same problem. Maybe he solved it somehow.

Could you quickly highlight what these configuration options are? Currently, as an admin, I find:

  • Disable ALL notifications for ALL channels with more than x members (under General → Notifications)

thats… it?

Thanks again @Andreas , @tom-s, @pjv, @toddy, @RPQ and @sleepawalker.white for all your valuable comments.

Thanks additionally to all those community members who have reached out directly to us on this, and I trust that we’ve all found a workable solution to accommodate your needs.

We are continuing to listen to every one of your comments.

Please allow me to recap the current situation for those who may be new to this thread.

Rocket.Chat the open source project has integrated the optional use of a mobile push notification gateway service, ran and operated by us, in order to facilitate the out-of-the-box experience of our community. The use of this service has been entirely optional for all on-premises deployed servers, and there exists alternate solutions in-lieu of using this service since day one.

Early 2019, we discovered and disclosed to the community that due to the increasing scale of adoption, we will soon need to start charging the heavy users of this external gateway service. Our intention is for the heavy users to subsidize for (the majority - 80% based on stats at the time) the moderate users in the spirit of the community.

We have been listening to community feedback since early 2019 and have started to take implementation action only in mid 2020.

As a result of the feedback, we are increasing our offer up to 10,000 free mobile push notifications (using our push notifications gateway) per month for any registered on-premises deployed server that decides to use our gateway.

We have also implemented a series of inexpensive Github sponsorship levels to satisfy most community needs up to a maximum of 20,000 mobile push notifications per month (for registered on-premise servers deciding to use our push notifications gateway). All existing Github sponsors already qualified for mobile pushes will have their cap adjusted by 5,000 per month accordingly. Github sponsorships are not stackable.

Again, for open source, NGO or similar organizations, or community contributors in hardship please just reach out to us if you need additional mobile pushes through our gateway, and we can work out something agreeable.

@TheUpsideDown and @RPQ, thank you for assisting in our situation. We are fully aware of, and in no way against, multiple community driven alternative gateways services. While we are unable to directly support your effort at this moment in time, we do appreciate it. Thank you again sincerely.

@pjv thank you for succinctly summarizing some community members’ frustration with our current notification implementation as we turn on the limit on our gateways.

Your two points are very well taken:

  1. control over messages already read not being counted as mobile push notification
  2. administrator’s ability to control per user usage of mobile push notification

To this we will add a third point, brought forward privately by another valued community group:

  1. control over per channel pushes – for devops shops having bots/automated webhooks/integrations that dump status messages into a channel

@milton.rucks is best able to address these concerns, and I would like to invite you to continue the discussion with him on this thread. Meanwhile, in consideration of your comments @pjv, we have extended the rollout of limits of mobile pushes going through our gateways to December 1, 2020

Thanks again to all, we continue to listen.

1 Like

Guys, have you thought of implementing an alternative way to deliver notifications without using push notifications - through background application polling, signalr, or something similar?

The situation is very sad

  1. For the 1st day of November, we received 882 push notifications … 40 users. We will spend 5k for a limit in 5 days
  2. Notifications come even when messages have already been answered.
  3. You cannot customize notifications to specific users.
  4. We can’t buy 1 month. Only a year. We are ready to pay every month for a user - but we are required to pay a year in advance.
1 Like

Let this be said as well - thank you people at Rocket.Chat for responding to our criticism.

On topic: I’m not familiar with Github Sponsors, but if @Alex.P is right, you should try and offer a monthly subscription. People are unsure about how their push usage will develop, or how this whole situation will play out. Even if you can win their trust - I’m not sure if it’s enough for a full year commitment. Plus SaaS users are used to Pay-as-you-go and monthly subscriptions…

1 Like

Thanks @nemhods and @Alex.P – Github sponsorship is indeed monthly with no term commitment. Please see details here.

You have to go into your GitHub profile and switch it to monthly. For some reason GitHub defaults to yearly. I believe if you click on a tier there is a link on the page before buying to switch.

Sign in to GitHub · GitHub I think this link will work to take you page to change it

1 Like

We tried to buy through an official reseller

Thank you for your response.

I have a question. Can you make a sponsorship for 20-25$ with raising the message limit to 30k?

4 Likes

@sing.li I’m with @sleepawalker.white on that. As explained to Luis in our conference call I’d rather support RC by supporting through the github sponsorship - or having custom pricing - than having someone third party monetizing your efforts (as someone indicated Update on Registration Requirement to Utilize Push Gateway) which would be less beneficial to RC as a company and us as users.

We might start with just 10k sponsorship though, but a high tier as sleepawalker indicates would be highly appreciated.

2 Likes

I think it would be nice to have the option to limit the number of notifications generated during a time frame.

For instance, if 10 messages are posted in a channel during a time frame of 1 minute, I don’t need to receive 10 notifications. I only need to receive one: I can then choose to immediately access the channel and see the new messages as they are posted, or instead I’ll wait for a while and then read the messages that have been written in the meantime.

Anyone using email notifications knows what I’m talking about. Inbox full of spam :wink:

This would also be a way to lower the costs of using the push gateway. It would be an opt-in configuration and configured by the sysadmin.

I opened a feature request with some suggestions (feel free to comment):

Also, thanks for listening to everyone’s complains and increasing the number of notifications to 10k/20k.

3 Likes