> My doubt is: what kind of information may the payload carry given that > it's generated by the user's server? Any use case for that? Thanks.
Right, this is why it has so far been desirable to just proxy the connection, so the app service has complete control over what it can know. These are the use cases I'd want to have covered at minimum: 1) Notification of offline messages, with the message bodies. 2) Notification that messages have been received while offline, possibly with a count of the unread messages. No message bodies or senders. This case is one that we've had to explore for dealing with services that must conform to governmental privacy regulations (e.g. medical) to prevent leaking protected data to external push services or across borders (e.g. a UK provider using push services based in the US). 3) Presence subscription requests, with requester. 4) Number of pending presence subscription requests (same situation as #2). One more that I'm not quite sure how we'd cover yet, but will become important soon: 5) Jingle call request/answered notification. As far as I can tell, those should be sufficient for general chat applications. More special purpose apps may require things like pub sub notifications, etc. — Lance
signature.asc
Description: Message signed with OpenPGP using GPGMail
