Final Update on Registration Requirement to Utilize Push Gateway

@sleepawalker.white I think that Gabriel did respond (or (had) others in the company (reply) for him). One of those was that hint on the sponsorships and I only just found this post.

In summary, writing as a community member and ‘willing-to-pay’ >15k user, I don’t hold much against RC for going taking path. You could even say that they are vary much softening the blow by announcing it a year in advance and actually having the promised ‘packages’ from back than in place. Using Github is a nice way IMHO, it’s readily accessible for most that way and a clear communication of ‘using open source’ (the right way).

What isn’t right is what Andreas is talking about in his post (just above yours). If those numbers are right something is wrong and a dearly apologetical post and personal mail should be in order.

In terms of pressing - I see multiple RC-members toning down on the ‘forced/upsales ent/pro’, though a sales-rep wouldn’t be worth his wages if he didn’t try to a) understand and b) convince a lead to go for a better package. We can all shout out ‘we wanted free, but willing to pay’ but we should also duly understand that RC wants to understand why we want to host things ourselves (which, in all honesty you’d have to agree, can be far more expensive). Let’s say for some sports team (see other thread) you host RC yourself and have a couple dozen participants - if you get hit by COVID and unfortunately hospitalized, that community is without their precious RC. Suddenly having the cloud-chat available makes sense.

For that same sports team $20(@saas) would still be way to much, and I’m sure the RC-reps wouldn’t try to squeeze there but you never know what special things they are willing to provide and it might be a better deal. Would they still start the conversation hoping to get a 200-person deal at ent? Sure! Wouldn’t you? But if they know the numbers they might be able to create a package that is affordable to the team.

So are you wrong?

  • Well, in communication they surely could improve. Still waiting for a date (about 19 days now) so I can turn PNs on again (or have my users live without them).
  • In making money, yes, open source isn’t free - even if it is. I’m a small contributor to Home Assistant and as such even got an additional pieace of hardware from a local store to ‘include it’. If I weigh the bought and free product (couple hunderd euros) against the time spend on getting it shared and up to date (even though we’re now a 3 man team), it’s never going to match up. But for me it’s a hobby, I improve my coding skills, and it makes people happy. For RC it’s their bread-and-butter, at some point in time they need to get something out of it
  • Are they exaggerating the PN costs? They might, we don’t know (neither should we probably). The proposal made in the other thread about ‘couple of $ per month’ is what they offer through Github. If their top 20% is checkout out at 60k PN/month and they need to support a neatly load-balanced setup of servers, that might cost an additional dev/ops resource just keeping that in check, personnel still is a costly thing (especially if that person can’t work on monetized projects/functionality that enterprise users are paying for to implement).

All in all, would I rather see a free or better way to implement PNs - yes. Am I looking forward to a sales-rep pitch - no, who would? Is Open Source free - no, it never was, nor will be - it’s a way of improving your own code and offer others the ability to chip in. Am I looking, as you, for a decent way to pay for a service someone else is spending money on - you bet, and (keeping in mind Andreas’ story) it should be for the right amount of PNs.

@tom-s What do you want to tell me?

What did Gabriel or someone else say for him somewhere? So we ask you to comment on the situation here.

That the path through GitHub is good? So no one argues. Just at the time of writing the comments (which are above) on the sponsorship page, there was no information from additional push messages, or links to their activation after donation.

You write “we wanted free, but willing to pay”. Find me this message.
No one says that. We all understand what you need to earn and no one condemns it. We are perplexed by the implementation of monetization of the project. It’s bad. And this is being talked about at least since JULY.

You write “For that same sports team 20dollars would still be way to much”. Well, let the sports team not buy, or buy a package for 5dollars. I want to know for sure that if I exceed the message limit, I can change it. Not waiting for the next month or until some Manager responds to me.

You write “need to support a fairly load-balanced setup of servers”. It’s funny, considering that the server performs only one function. Even I, not a system administrator, understand this.

You’ve written a lot of other things, but …

“or have my users live without them” are terrible words that make me lose heart. Because of them, I no longer want to participate in the community.

2 Likes

@sleepawalker.white don’t overheat things that don’t need cooking - you asked for others opinions, you got my 2 cts. To clarify further, unfortunately again lenghty:

  1. I’m - like you - a community member, using a (self-)hosted version - so no, I’m not a part of RC
  2. I’d like to have things for free, but there is no such thing as a free lunch (or … if you ain’t paying you are the product)
  3. My users like PNs, but if there is no affordable & agreable way, they and me are either loosing out on PNs - or - we need to find another product, which, in time, will be charging for something
  4. If, instead of just ranting, you’d actually read the topics to which you replied you would know what references I made and that sportsteam got offered something high and - like you and me - just looking for >15k options.
  5. About wanting free beers, but willing to chip in. Thats a general approach (and thus misconception) with Open Source, just as horsing around authors and contributors into doing what you think is best for them (or rather, for one self). It’s their product and their choosing.
  6. There is no clarity how to get >15k, like you, me and others, we’d like to see that. The difference between you and me is, I’m (im)patiently waiting for the sales rep. Why? Because they don’t have on display what I’d like.

Going from 6 - If I go to a store that ‘should’ but ‘hasn’t’ got what I desire, I mostly speak to someone in charge if there is a ‘different way’. That might become a special/custom selection or they might find it feasible for all customers, anyway, up to them. Or I take my business elsewhere, that could be the stores loss, or mine. In saying that:

If you add all of those up, RC is - imho and pending a talk - still the best option out there currently. You asked about what others thought, I wrote mine. No reason to flame.

I feel like we’re talking about different things.

Don’t see any point in repeating it and chewing it again.

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