@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.
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.
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.
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.
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.
@reetp The first place you will see the notifications usage will be on your cloud account, we can’t update all the old Rocket.Chat versions to include this usage but new versions will came with a easy way to consult the usage from inside the server as well.
We will not start charging before finish the notifications page on our cloud UI.
Yes I’m waiting but nothing so far, but you must be able to monitor it already. Why can’t we? That is what I was told I’d be able to do, and I can’t.
You have hustled us into creating all this cloud nonsense with threats of cut off dates for notifications, and told us we’ll be able to see how many notifications we are sending. So far all I can see is a link that doesn’t work. Hardly world class is it? Just smacks of the usual botched implementation and mismanagement seen here time after time.
we can’t update all the old Rocket.Chat versions to include this usage but new versions will came with a easy way to consult the usage from inside the server as well.
It should have been there ages ago and there is really no excuse why not. You have just used it as an excuse to bully people into creating an account.
The fact that it will be included in the future - well, great. Just a year or two too late really.
We will not start charging before finish the notifications page on our cloud UI.
Oh how relaxed I now feel with that reassurance. How many weeks of monitoring am I going to get??
Well, it would be nice to have some idea about this like NOW. Or even a year ago when it was all raised. I asked about it then, and it has been completely ignored as usual. Why hasn’t this been implemented ALREADY???
Point is that despite all this upheaval no one is ANY the wiser as to their usage even now.
This should have all been sorted LONG before you ever tried to launch it. Proper tools and monitoring put in place. It isn’t as if this is a surprise to Rocket is it?
It has just made Rocket.Chat look like a bunch of amateurs, which is what I tried to prevent when I first raised these issues.
@reetp I’ve already proposed a solution to this problem which would eliminate the push notification charges completely, but, if there is no collective desire to fund the development cost, it just won’t happen.
Sheesh… nice. However, I don’t think it is ‘fire & forget’ easy setup for many small operators as it has been. Also how does it work with iOS devices?
In any event you have to understand the reality is that is not part of their gameplan.
They are a just business (the open source ethic got hijacked some while ago - it is now just an advert to entice you to the paid for options). Like any biz they can’t afford to lose money. They need users, and data. That’s where the money is.
That’s the point of the logins & cloud nonsense. None of it is ‘needed’. They could have put notification counters in Rocket years ago but didn’t bother so they could force you to open an account, track usage and feed you unnecessary and fvcking annoying notifications (which will soon turn to ads & upsell products no doubt).
There is a whole bundle of business stuff behind the scenes which we are not privy too and drives things. That’s why some decisions make no sense. You don’t know all the info that led to it. The roadmap is not open.
Note, my own usage is non existent and it won’t really affect me.
I’m also way more of a business person than a dev. I have a reasonable understanding of how it works.
It’s been sad to see the money take over and the slide away from genuine open source.
I’m just standing up against hype, hyperbole, and marketing waffle, and for open source.
I agree. The decision to extract income from their push notification gateway is not in the best interests of the project. I think that selling support services and integrations would be a much better option. At the same time the AWS gateway implemented by the RC team is also costing them money, so eliminating it would reduce their costs considerably.
It would be fire and forget. The only extra step would be that each RC host would need to open a free firebase cloud messaging, FCM, account to generate their own private key and sender id (public key) for the project. Those keys could be stored in the RC database or passed as environment variables on startup. The push notification system works for both Android and iOS devices and Google do not charge for messages passing through their servers.
