Include full stanza with encrypted push notification
weiss opened this issue · 3 comments
I'd be interested in seeing your encrypted push notifications spec being standardized. I think it's nice and straightforward, so thanks for publishing it!
The one thing I'm unsure about is the design decision to pick individual elements, such as the message body, groupchat nick, or Jingle negotiation stuff, rather than simply including the entire stanza. With the current solution, the spec and the server implementations would have to be extended whenever some client needs another field for some reason, like you already had to do for Jingle Message Initiation and OMEMO.
I guess the motivation of your approach was minimizing the amount of data, as both APNS and FCM limit the payload size to 4 kB. However, I'd assume that hitting such a limit in practice will usually happen due to a rather long message text, rather than huge amounts of additional XML elements, so the win in omitting those will usually not be all that significant. And the spec could still allow (or explicitly suggest) the server to remove uninteresting elements and/or truncate unencrypted <body/>s.
Either way, if payload size does end up being a problem, another option might be compressing the data?
As you mentioned, the issue is with payload size. The limit is usually around 4kB, but we need to encrypt this data, which gives us a binary representation of the encrypted message stanza and we need to make it compatible with XML (encode it with Base64). As a result, we have only 3kB available for our payload.
Moreover, while your approach would be far more extensible, it would be a lot more verbose, ie. Jingle messages would contain Jingle elements with their namespaces (which are not short) and in the case of OMEMO we would have encryption key encrypted for each device to which this message is addressed.
Moreover, typically messages contain now not only the body but also origin-id, stable-id, references, etc. I know that this will for sure make payload bigger and while stripping those unnecessary data (now) could work at some point we will be faced with an issue that some servers will strip something, others will not and we will end up with a situation (which we already had with push notifications) that we do not know what we can expect. What will be sent always? What is always stipped? What is never stripped?
If we would decide to go with this approach, then we would have to give control of what is sent in the encrypted payload to the client, ie. to allow the client to send XSLT document, which the server would use to "generate" XML which would fit in the 3kB limit and at the same time contain data usable for the client.
Actually, after some thinking, this approach with XSLT being shipped from the client would work the best. The issue here however might be with XSLT transformation taking some time and being problematic (in some cases) on the server-side, but that would be the most flexible approach and easily adjustable in the future by future clients supporting new XEPs.
As it was suggested in this thread: https://mail.jabber.org/pipermail/standards/2018-August/035298.html, usage of XSLT may not be a good idea, so usage of some custom specification for filtering and stanza transformation (possibly based on XPath) could be used instead of XSLT.
some custom specification for filtering and stanza transformation (possibly based on XPath)
I understand your reasonings, but I'm afraid the end result might no longer be that "nice and straightforward" as your current solution. As usual, there's a 'simplicity vs. flexibility' trade-off.
Maybe it's better to just ignore my inital comment and go for suggesting your solution as-is, on the basis that 'perfect' can be the enemy of 'good'?