[Standards] XEP-0357: Adding last-message-priority

Thilo Molitor thilo at eightysoft.de
Sun Jul 30 01:02:57 UTC 2017

I'd rather suggest something less client specific.
The requirements which stanzas are high priority and need special treatment 
vary from client to client.
Letting the server choose, which stanzas belong into which category, seems to 
be the wrong way.

My proposal (well...essentially it's Holger's) is to let the clients add an 
"include_payload" attribute to the enable request.
This attribute can have the values "none" (the default) or "stripped".

If it is set to "stripped", the published <notification/>s would include a 
<payload/> child which holds a stripped version of the whole stanza.

Stripped in this context means exactly the following:
All stanza contents and all attributes except the "type" and the "xmlns" 
attributes are removed.

Here are some examples to illustrate this:
<!-- A chat message: -->
<message type='chat'><body/></message>

<!-- A PEP/PubSub event: -->
<message type='headline'><event 

<!-- A Jingle session initiation: -->
<iq type='set'><jingle xmlns='urn:xmpp:jingle:1'/></iq>

The advantage of this proposal is, that the decision, which stanzas trigger 
which notification, lies entirely by the client and not the server.
The client can choose not to include any (stripped) stanza or to include the 
stripped stanza so that the app server can decide how to trigger a push 
notification on the client device and what this notification should be like.
Even when sending the stripped stanza along with the published <notification> 
it contains no message contents or something like this and only metadata 
reaches the app server.
This should provide a decent privacy and at the same time give the app server 
enough information to do it's job when needed.

As a proof of concept I will implement this behaviour in prosody's 
mod_cloud_notify in the next couple of days.

Am Donnerstag, 27. Juli 2017, 18:23:56 schrieb Chris Ballinger:
> This adds an optional "high" and "low" priority value, where "high" depends
> on whether the message contains a <body> or <encrypted> (OMEMO) element.
> This helps limit overly verbose push notifications for things like typing
> notifications, without requiring transmission of anything about the message
> contents.
> The suggestion is that "high" priority pushes trigger something visible to
> the user, whereas "low" priority pushes can be filtered or sent as
> background fetches.
> This is a simplified variation of an earlier proposal that defined multiple
> message types.

More information about the Standards mailing list