After a few more days of thought I'm not fully happy with the priority idea because it doesn't really leave room for any other states other than new message notifications. There may be other types of high priority that would be helpful to include with static notifications, like invites, which aren't covered satisfactorily.
There is another proposal to include stripped stanzas, and while I think it offers the most flexibility, I am concerned that buggy (or even correct) implementations could leak too much info, and that it adds too much complexity to the pubsub node to parse the many different types of notifiable stanzas. >From my perspective I want the least amount of data possible to make a satisfactory user experience. Running the pubsub node and push API exposes a central point of failure, so I really want as little data as possible to pass through our servers. As a bonus, preprocessing the stanzas into a simple string enum type within the XMPP server before sending it over means that app developers running pubsub nodes don't need to each write their own stanza handling code. last-message-type is probably the best in terms of trade-offs for my use case. There are a minimal number of values that need to be supported for basic functionality: 1. "message" -> hint to show "New Message!" 2. "invite" -> hint to show "Someone new wants to chat!" 3. "invite_group" -> hint to show "You've been invited to a group chat!" If you're a server operator that is concerned with privacy, you can send over just (1) and still have a satisfactory UX. Sending over (1,2,3) doesn't remove that much in terms of privacy either. The additional types I'm listing below _could_ be sent by the server, but perhaps should be disabled by default, and only enabled when you're using a vertically integrated XMPP stack and don't care as much about user metadata leaks. The below could also be filtered out by the pubsub node because it can cause major battery drain if these are constantly waking the app in the background. 4. "typing_start" 5. "typing_end" 6. "receipt" 7. "read" It could also be extended to other future types: 7. "call_audio" -> "Incoming audio call..." 8. "call_video" -> "Incoming video call..." If you want to get really fancy you could allow the spec to include multiple types separated by a space, to allow a fallback to recognized types. Or I guess you could just fallback to "message", or simply ignore unrecognized types. On Thu, Jul 27, 2017 at 6:23 PM, Chris Ballinger <[email protected]> wrote: > 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. >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
