|
Unknown opened 4 years ago
|
|
|
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 Moreover, typically messages contain now not only the body but also 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. |
|
|
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'? |
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?