I don't like the idea of different "message classes". It is difficult to define classes that every client developer is happy with. And new XEPs could add the need for more classes, too.
Every time, a new class is defined, this has to be added to the XEP and implemented on the server side. Every server operator has to update his software so that clients using these new and/or changed classes could be used properly with this server. In contrast the stripped stanzas proposal is flexible enough to allow the app developers add new types of push messages when the need arises. Usually the team developing the appserver and the client app is the same so this integrates the definition and usage of new push types tightly into the developement cycle of the app in question. The stripped stanzas proposal can even extended further allowing the keyword "full" for "include_payload" in addition to the keyword "stripped". Clients specifying "full" will get a copy of the whole stanza which is useful in a trusted environment where appserver and xmpp server are operated by the same entity. The "full" keyword also has the advantage that the underspecified "push summary" currently defined by the XEP could be removed. The stripped stanzas proposal allows the client to define, what additional info should be sent to the appserver (nothing, stripped stanzas or full stanza copy), shifting the decision to the client instead of the server operator which is good for privacy reasons. Currently a server operator can accidentally activate the "push summary" on his server and evey app server will get the last message body along with the message sender. The stripped stanzas proposal doesn't have this pitfall at all. So to summarize: - Including "full" alongside of "stripped" and "none" allows us to remove the underspecified and rarely used "push summary" from the XEP while still maintaining compatibility with scenarios where this information is actually needed/wanted - My proposal allows the client to specify what information it wants to be sent alongside of the push instead of the server operator - My proposal is flexible in regard of future changes to the XMPP protocol - It allows a much faster developement cycle for app developers because they don't have to wait for xmpp servers to implement new push types Am Sonntag, 30. Juli 2017, 13:22:02 schrieb Chris Ballinger: > 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 <chrisballin...@gmail.com> > > 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: standards-unsubscr...@xmpp.org _______________________________________________
