Push message: This is an array of bytes (ByteArray) sent by the application server to the push server. The distributor sends this message to the end user application. It MUST be the raw POST data received by the push server (or the rewrite proxy if present). The message MUST be an encrypted content that follows RFC8291. Its size is between 1 and 4096 bytes (inclusive).
It doesn’t matter. Even if the ntfy message was plaintext, that plaintext content would be a UnifiedPush “Push message” which is the RFC8291-encrypted raw POST data.
So, for example, if one were to register Unified Push notifications with Matrix using Ntfy, the creation of the encrypted Unified Push notifications would be done by the Matrix Unified Push Gateway which then gets handed off to Ntfy? Is there a way to confirm that the received notification is indeed encrypted?
I enabled logging in the Ntfy app, and, upon receiving a message in Element X, it showed the Matrix notification push message in plain text in the logs. If Ntfy indeed doesn’t know anything about Unified Push and is just the medium through which a Unified Push message travels, then I would think that it wouldn’t be the service decrypting the message, yet it is decrypted in the logs.
Yeah, I was doing some more reading and I think it might only be the newest version of the UnifiedPush spec which requires the message to be encrypted.
Yeah, I was doing some more reading and I think it might only be the newest version of the UnifiedPush spec which requires the message to be encrypted.
The question I would then have is: Who would be responsible for updating their system to support this (ie the Unified Push encryption)? Say if we, for example, look at Matrix. Would Matrix need to modify their notification API? Would the Matrix gateway in Ntfy need to be modified? Would some other component of Ntfy be modified? Would the distributor app need to be modified? Would the end-user application need to be modified?
Regarding encryption of the push message, from https://unifiedpush.org/developers/spec/android/ :
What’s interesting, and is confusing me about this, is that Ntfy does not adhere to this [1]. I’m not sure how this can be.
References
It doesn’t matter. Even if the ntfy message was plaintext, that plaintext content would be a UnifiedPush “Push message” which is the RFC8291-encrypted raw POST data.
So, for example, if one were to register Unified Push notifications with Matrix using Ntfy, the creation of the encrypted Unified Push notifications would be done by the Matrix Unified Push Gateway which then gets handed off to Ntfy? Is there a way to confirm that the received notification is indeed encrypted?
You could have a look at the messages ntfy is passing around using its trace function: https://docs.ntfy.sh/troubleshooting/
I enabled logging in the Ntfy app, and, upon receiving a message in Element X, it showed the Matrix notification push message in plain text in the logs. If Ntfy indeed doesn’t know anything about Unified Push and is just the medium through which a Unified Push message travels, then I would think that it wouldn’t be the service decrypting the message, yet it is decrypted in the logs.
Yeah, I was doing some more reading and I think it might only be the newest version of the UnifiedPush spec which requires the message to be encrypted.
I noticed that the examples given on https://codeberg.org/iNPUTmice/up/src/branch/master/README.md are unencrypted.
The question I would then have is: Who would be responsible for updating their system to support this (ie the Unified Push encryption)? Say if we, for example, look at Matrix. Would Matrix need to modify their notification API? Would the Matrix gateway in Ntfy need to be modified? Would some other component of Ntfy be modified? Would the distributor app need to be modified? Would the end-user application need to be modified?