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
wrote:
> This adds an optional "high" and "low" priority value, where "high"
> depends on whether the message contains a or (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: standards-unsubscr...@xmpp.org
___
