Is there any appetite for this new addition to the base Pushover API?
As described, this provides End-to-End Encryption for specific parts of Pushover requests - namely the message, title, url and url_title. It does not cover elements such as attachments or sounds.
Pushover already uses TLS for communication to and from their servers. E2EE would simply be an additional security layer for integrators who wish to hide sensitive information from the Pushover servers.
Happy to put together a PR for this.
Isn't this something like MQTT but specifically for messages?
A while ago I wrote an app for my android phone to privately send my location back to my computer using MQTT..
But android/google blocked it from working on their next update.
Pushover is an application of HTTP, more specifically for push notifications on Android and iOS, although there is a desktop version of the client too.
MQTT is a protocol, it sits at the same layer as HTTP. It's more of a two way protocol, and it's really good for getting shared data to lots of different end points reliably.
Ok, thanks.
I think this is beyond my scope of knowledge.
Better/more security is always welcome! I don't use Pushover myself but if it is easy enough to implement, I would think that people would welcome it.
Comparison of MQTT and PushOver...
| Feature |
MQTT |
Pushover |
| Primary purpose |
Device-to-device messaging |
Human notifications |
| Typical use |
IoT, sensors, automation |
Alerts to phone/tablet/desktop |
| Communication model |
Publish/subscribe |
Send notification to user |
| Requires broker |
Yes (e.g. Mosquitto) |
No |
| Internet required |
Not necessarily |
Yes |
| Phone notifications |
Not directly |
Yes |
| Two-way communication |
Yes |
Primarily notification delivery |
| Real-time data |
Excellent |
Not intended for continuous data |
| Message frequency |
Very high |
Designed for notifications |
| Payload |
Almost anything |
Text + notification options |
| QoS |
0, 1 and 2 |
Handled by Pushover service |
| Offline/local operation |
Excellent |
No |
| IoT suitability |
Excellent |
Poor |
| Human alerting |
Possible, but inconvenient |
Excellent |
Net is - yes please - a PR would be great as long as the base functionality continues to work.
I don't want to hijack this thread.
This application.... It needs IP addresses to work.
So I can't see how it is usable on a mobile phone sending message back to base - or more so: vice versa. (From base to the phone) as the phone doesn't have a fixed IP address.
But: I digress. This is way above my skill set.
I've noticed that this node is an implementation of an npm library, node-pushover. Decided to submit a PR upstream first, I think it makes sense for the encryption algorithms to live there. Also gave me a chance to update some deprecated methods used by that library.
No changes to base functionality - E2EE remains optional.
If the author accepts, I'll update this one next.
