Update on Registration Requirement to Utilize Push Gateway

Announcements
1

Dear Rocket.Chat community

We want to make it very clear that what we are imposing right now is just the registration requirements for sending push notifications and not the limits on how many notifications can be sent. This requirement has already been stated over a year and a half ago, and we just haven’t imposed it until now. So we believe we have given enough time for people to prepare for this change.

Having said that, we apologize for the confusion we may have caused. We should have been more clear about the next steps and future options for continuing to use push notifications.

  • We will extend the grace period to enforce the registration in 2 weeks, from July 31st to August 14th, in order to solve any remaining issues in the registration process and give you all enough time to finish the process.
  • We will add the push notification count to the statistics on the admin panel, both daily and monthly usage, so the server admin will know in advance the current usage and trend with enough time to make a decision on how to address the usage.
  • We will not enforce the limit to the push notification gateway usage without a sufficient transition period of at least one month, in some cases more if requested.
  • We will always allow organizations and communities to build and use their own mobile apps with their own credentials to send push notifications directly to Apple and Google.
  • We will increase the push notification limit of the PRO edition from 10k to 25k push notifications per month.
  • We will continue to support Non-Governmental Organizations, Educational Institutions and Open-source Communities by providing special discounts.
  • We will increase to 5k the free push notifications for any registered servers, that from actual metrics this will cover the needs of over 80% of the active servers.

After hearing the concerns from our community about the big investment step that moving from the 1k free push notifications to a PRO license represents to non-profits, small organizations, individuals, and communities, we decided to provide an extra option: A few months ago we created several sponsorship tiers on Github. So to make the sponsorship more rewarding, we will increase the limit by 5k push notifications per month for a server of contributors of 5 USD per month and extra 10k for contributors of 10 USD or more.

The 10k limit will cover the needs of over 90% of the active servers. We believe this is a great way to not impose unreasonable costs on our awesome community while incentivizing everyone to support the project they use and love, making it grow even faster.

IMPORTANT: We are still trying to define how we will be able to automate this process, but most likely, we will have to move the sponsorship options away from Github into our marketplace that already has this functionality.

IMPORTANT: We are also looking into adding to the sponsorship plans, the full encryption of the push notification messages, a feature that was only available for the enterprise license, but we need to figure out some technical details about how to do so.

I trust you understand at all we are doing is working hard to make rocket.chat grow better every day, and we do need your support to do it.

Regards,

Gabriel

4 Likes
3

I was reminded of this.

"But the plans were on display…”
"On display? I eventually had to go down to the cellar to find them.”
"That’s the display department.”
"With a flashlight.”
"Ah, well, the lights had probably gone.”
“So had the stairs.”
"But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.

Douglas Adams, The Hitchhiker’s Guide to the Galaxy

===============

So, thanks for the message but it is just platitudes & excuses.

No one has properly explained why a cloud login is actually necessary. Plenty of waffle. No substance (see hypocrisy further down) The instance knows how many notifications it sends. Because it seems you do? But you said you didn’t? How…odd.

Stats for this have been requested to be put in an admin panel… probably as long as you have mentioned limits (I can’t be bothered to search the bugs as I’m off on a weekend break. Go look yourself). Rocket could have fixed this a long time ago so users could track their usage, but as usual didn’t bother. Or ‘Enterprise’.

So don’t blame users for your own failings. They could have helped reduce usage, with the tools.

The cloud account is therefore just tracking, pure & simple.

Next, fix your code that still pumps out large numbers of unnecessary or unwanted notifications (see Aarons thread for my comments, and others, on the large number of wasted ones that you now want me to pay for. I don’t have time to waste on more duplication)

Maybe that will save you more than a few bucks, and a lot of irritation for users.

Fix the problem. Don’t just stick an expensive plaster over it as usual. A plaster you expect people to pay for.

Last, the one that really annoys me.

Limits. You contradict yourself so many times it is embarassing. I don’t have time to quote you on it all right now. I’ll save that for later.

You say we need a login to monitor notifications. But you seem to already know the stats. So why you can’t give us those stats already?

You say 1,000 will cover 70% of users (show us the data).

And 10k 90%?

Those are some odd numbers.

70% of all your users use less than 1000 notifications? A lot of very small users then?

But but but… you also said you only wanted to charge the top few large users.

I already did the maths on this. Either you have a lot of instances with 2 users who don’t talk to one another, or you can’t count. But I don’t know which without the stats.

Lets try something simple for you.

1000 / 20 working days / 5 users = 10 per day.

Seriously? That’s a ‘large’ user? (‘We only want to charge a few of the large users’)

If it is you have serious issues because you’ll earn next to nothing out of them. So I know you’re kidding really…

My small group sends way more than that, 90% of which we don’t even need because browsers are open… the system is a completely unreliable kludge with no fine grain control.

But the 5 or 10% are really important. How do you work that out?

I wouldn’t say we were high use by any means. We use far more than are needed, but you don’t give us the tools to help ourselves. I can’t mute or limit in any reasonable way. Because… see previous. Easier just to charge us, isn’t it?

So somehow nothing adds up. Despite these things being known a long time, they have been ignored. I see lots of excuses and platitudes and jolly bloody hockey sticks, and no real action to deal with any of the issues raised. Two extra weeks? Ooooh. Fab. I’ll take a week off then, and have a week to spare. Joy.

I’m off to chill as you have just completely screwed an otherwise completely awful week and I badly need a drink.

Hopefully your lot will sort out some of the mess they have created before you start ripping them off.

========

“I love deadlines. I like the whooshing sound they make as they fly by.”

7 Likes
6

Because you are consuming a service we are providing, the same way we are required to have logins with Apple and Google and pay them yearly fees to use their push notifications services. These services have polices we have to follow, and in order to do so, we need to control the usage of our gateways.

You are welcome to cut the middle man, us, and deal directly with them.

What part of that is so hard to understand?

Why odd? The instances were not storing local data about the usage of push notifications, but we were able to measured usage by counting hits form workspace IDs to the service.

This is factually incorrect. You can change the setting for the server not to send push notification on ALL MESSAGES by default, and only on mentions. User can override that per account or per channel. Are you not aware of this possibility?

1 Like
7

Except those settings don’t seem to be helpful considering my instance likes to send push notifications to my phone about half an hour after i had a DM conversation with someone else over the desktop client.
I don’t know if there’s just something wrong with my phone or the server but my assumption of how the feature should work is: If the user is online using the web or desktop client and hasn’t marked a message as read within a given timeframe, send a push notification to the phone. This doesn’t seem to be the case.

I wouldn’t want to get charged for such notifications.

2 Likes
8

Is not your instance. That’s the buggy push notifications systems they pretend to charge us.

I’ve been using RC just with the IT team during the last year, before going into production. I like to test extensively the self-hosted solutions before going into production. That team can use the 1000 limit in just one day, because all of us work from home. So that “free” account never will be free.

Privacy also matters. I’ve installed RC having in mind precisely that. Tracking cookies, RC having access to our messages, pushing themselves messages to my server… that’s completely insane.

I’m so disappointed I’m leaving rocketchat to Matrix, a true open source and enterprise chat solution. No strings attached.

Good luck to you all. I really hope someone can fork this, like Libreoffice did with Openoffice or other cool projects forked from rusted ones. If not, we can see us in Matrix.

2 Likes
9

Some guide for moving data from RC to Matrix would be nice.

10

This is definitely a bug, the system is expected to work as you described. Can you please open an issue with more details about your deployment?

11

UPDATE: We are changing the proposed free push notification limit from 1k/month to 5k/month. and splitting the sponsor plans into 2:

  • 5 USD/month for extra 5k push/month
  • 10 USD/month for extra 10k push/month

And let me please explain why I use the word proposed:

The reason we are asking servers to register now, and not imposing any limits, is exactly because we don’t have enough data about usage profile to be able to confidently determine what are the right ranges. I have already stated that admins will have had the reports about their usage and trends for months before we finally decide and enforce any cap.

Based on the feedback here, rather than just using just the statistics we collected by counting unique sources hitting the server, we tried to discard test and demo servers from the calculation by removing all sources with less than 100 push sent per month and sources that only hit the service for a short period.

Once we gather data from registered servers and you know how much you are really using, we can take the informed discussion about the limits.

We are also looking into adding to the sponsorship plans, the full encryption of the push notification messages, a feature that was only available for the enterprise license, but we need to figure out some technical details about how to do so.

I trust you understand at all we are doing is working hard to make rocket.chat grow better every day, and we do need your support to do it.

Regards,

Gabriel

12

Today, I am trying to register and it does not allow me to authorize the server so that it can sync with https://cloud.rocket.chat/
when performing the step to log in and synchronize the server with the cloud account, it shows for a very short time the authorize button which does not give an opportunity to click when it again shows the cloud login view

13

What version of RC are you running? The push notification queue cleaning algorithm may be faulty in this case and we’d like more info to investigate. Or, if the message was indeed older and just arrived late, the problem may be a overload on our gateway… and that’s one of the reason we want to invest more on it.

14

If you clicked login from inside of your workspace. It sounds like the registration portion is done. Try hitting sync on the connectivity services page. Then once it finishes try to login again. It does an oauth login and the redirect uri has to match otherwise it fails to let you login.

15

new user here - currently having a look at rocket and matrix - and - as i found this topic not really sure about the truth behind what the webpage (unlimited & open-source…) promotes.
So - yeah - until that is clarified thats a big minus on the checklist when i compare the two solutions.

My company has no problem paying for software - beeing a patreon, participating in bucket lists to implent wanted features, cashing in a yearly support subscription etc. - but the planned implention is one of the worst solutions i can imagine.
If i understand right currently the open source version differs from the enterprise in terms of some additional features. But now another limitation - that of messages per time is planned/already pushed through?

Guess you have to change the comparison/pricing page - as the big fat free that is listed under the community edition (according to the provided comparision “recommended up to 1k users”…) isnt exactly the truth.
This is the same bullshit definition as with free games - where there is ingame payment needed to progress or flatrates for mobiles - that are limited to whatever GB you pay… A flatrate is either unlimited - or not a flatrate.
If you dont want to support a community edition without getting some payback for the time involved just say it out loud - because that is how this reads to a new user. There is nothing wrong with that. But it should be communicated openly.

About Rocketchat vs Matrix
The main thing i could not yet find out about matrix is, if there is a possibility for a guest to write into a specific room (support chat) - a live chat feature embedable into a website.

Does any of you use this feature?

about moving date - i havent tried - but i found matterbridge as possibility to link the two. not sure about existing data though.

1 Like
16

Hi,

Sorry if this is written somwhere already.

But if we use our RC only inhouse, with no external connections except smtp pushes.
Do we still have to register, or how does this work. (we have registerd our installation at the beginning of time :slight_smile: )

Or is this “only” for using your aws pushgateway to other services?

–
Regards Falk

17

For using the push gateway and the internal apps marketplace.

18

@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.

19

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
20

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
21

Only mobile app notifications use the push gateway.

22

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

1 Like