Push Payload Changes

[ismailgulek]

Change content-available to mutable-content and also add event_id in payload if provided. This is intended to enable modifying push notification content on the client side (iOS). For details:

element-hq/element-ios#2714

[babolivier]

I'm not an APNS expert, but this doesn't sound backward-compatible to me. Could you please define the new property as well as the existing one, not instead?

[ismailgulek]

@babolivier thanks for the review. I'll try to explain the change as far as i can.

content-available key is used to make a notification silent, when the key is set to 1, alert, badge and sound keys should be omitted. Detailed info about silent notifications is here.

mutable-content key is used to make a notification modifiable in client side. We will use this mechanism as a replacement of VoIP pushes and our intention is to modify notification content (e.g. decrypt event) and if we fail on this, we'll still have some generic content to show (e.g. "Somebody sent you a message"). Detailed info about modifying notification content is here.

Actually our usage of content-available key was useless because we were also setting the alert and badge keys. So these notifications were not silent. Indeed, we were not using regular notifications at all, but VoIP pushes.

Detailed info about payload keys can be found here.

[babolivier]

@ismailgulek Right, so neither content-available nor mutable-content are actually passed on to clients?

[ismailgulek]

@ismailgulek Right, so neither content-available nor mutable-content are actually passed on to clients?

No, they are both passed. But they don't help us at the moment, because we're using VoIP pushes. They will be important with our new development.

[babolivier]

No, they are both passed

Right, my point is that Riot isn't the only mobile client that's using push so we should care about backwards compatibility in case one actually does something with these parameters.

[ismailgulek]

No, they are both passed

Right, my point is that Riot isn't the only mobile client that's using push so we should care about backwards compatibility in case one actually does something with these parameters.

It should not affect any other clients, as they already should be using VoIP pushes. Even if they don't, as i stated earlier, it's useless now.

This concern has been evaluated and we consider it unlikely to backfire on us in the future.