The mobile app integration has support for push notifications. This allows this app to register as a target. To do so, we should set push_token and push_url during the mobile app registration from #5 (docs). We can use the same one as iOS.
@robbiet480 could you briefly explain how to get push_token and push_url?
push_token comes straight out of the Firebase SDK. push_url should be set to https://mobile-apps.home-assistant.io/api/sendPushNotification. That is a generic endpoint which supports both iOS and Android (and web too). We can get @CedrickFlocon added to the https://github.com/home-assistant/mobile-apps-fcm-push repo (currently private so that people can't find possible bugs to allow bypassing the rate limits) and I am happy to spend some 1 on 1 time with them tuning the server side code to best support Android push notifications.
I put the very basic building blocks in at #96. As a side note, the https://github.com/home-assistant/mobile-apps-fcm-push repo is now public.
Is there any particular reason to not implement fcm directly into HA other than imposing a message limit on users?
Ariela and others do it and I'm not aware of any issues with that approach.
https://github.com/MCrissDev/HANotify
@MCrissDev did you encounter any issues with that approach?
@quthla We aren't interested in that path because it adds a lot of extra complexity. We'd have to distribute keys in code and have issues if we needed to rotate them. I'd also worry about hitting FCM rate limits.
Also AFAIK Ariela is moving towards the mobile_app notify system as well.
Okay, I just wondered because on the website it says "home automation that puts local control and privacy first."
Notifications should at least be end to end encrypted then to ensure the privacy HA promises.
@quthla It would arguably be worse to implement FCM directly in HA due to the key distribution issue. The keys would have full access to at least all of the Firebase APIs as Firebase doesn't support keys scoped just for specific APIs such as FCM. This would allow anyone to list all of the tokens ever registered on the apps and spam as well as possibly influence end users Home Assistants.
End to end encryption has been suggested and I would like to implement it, but even then we can't fully encrypt the payloads because FCM and APNS require being able to inspect the payloads for fields like badge or sound to be able to properly notify users.
@robbiet480
End to end encryption has been suggested and I would like to implement it, but even then we can't fully encrypt the payloads because FCM and APNS require being able to inspect the payloads for fields like
badgeorsoundto be able to properly notify users.
At least for Android that is wrong because the app builds the notification instance itself.
@robbiet480 Please see this example to understand how FCM works on Android.
I think the data you mean is only required if the app does not implement its own FirebaseMessagingService.
That is true of the latter fields but the first link I shared contains things that the OS and FCM deals with such as priority, ttl and collapse_key. Those are things that can't be encrypted.
That is correct but those fields are not necessarily needed and should not contain any sensible information anyway.
priority is required for proper delivery to Apple Watch as of iOS 13 and watchOS 6collapse_key on iOS and I'm sure they'll come on Androidbadge and sound. Firebase allows us to present a universal solution for sending notifications to both platforms. This allows us to do things like have one set of documentation and only have to deal with one set of syntax issues. I think it would be more detrimental to have to split the infrastructure into iOS and Android specific setups.Again, I'm not opposed to end to end encryption, it just has tradeoffs and isn't a priority for me. We absolutely have a strong mandate for privacy and I want to respect that, but at the same time thus far I'm the only one who has put time and effort into building notification solutions on either platform as well as the server side and I just want to get things working as simply as possible, for now. If someone is willing to step forward with a solution on both the client side (most likely both platforms I might add) and server side to implement end to end encryption, then we would absolutely welcome that. For now, yes, people are putting their faith in us that we (the core Home Assistant team) aren't doing anything nefarious with their notifications.
I was only referring to Android. It's been quite a while since I worked with notifications on iOS.
Even with end to end encrypted notifications on Android you can still use Firebase. It just requires some slight modifications to the mobile_app integration and the lamba(?) code to forward the encrypted payload to Firebase.
And I'm not really worried that you could do anything with the notifications but there's also Amazon and Google. And when there's any easy technical solution to ensure privacy, then that should be went for.
Most helpful comment
Okay, I just wondered because on the website it says "home automation that puts local control and privacy first."
Notifications should at least be end to end encrypted then to ensure the privacy HA promises.