вт, 3 сент. 2019 г. в 19:15, Ralph Meijer <ral...@ik.nu>:> > Hi, > > Let me start out saying that, like Philipp, my reading of the current > version of XEP-0353 is also that there is additional information shared > with the client over FCM/APNS. However, I must also say that neither > XEP-0353 nor XEP-357 make it clear how this should work exactly. This is > a problem, because it results in proprietary solutions for doing the > same thing. At minimum this should get another look and more concrete > examples with how existing push services would *actually* be used. > > Andrew's description of their use of XEP-0353 introduces new elements in > the existing namespace, and adds a new iq-based exchange. Assuming this > is an experiment, I do want to point out that before it would go into > actual use, those would need to be moved to their own private namespace, > or be included in a next version of this specification (which might > require a new namespace).
I agree that our approach changes 0353 significantly. Since we DID implement 0353 in its current form to the letter and discovered that it can't work well on iOS without additional roundtrip. So it is unlikely we'll support this XEP without changes. If our approach won't be accepted into 0353, we'll move it to another namespace and treat is as a new protocol, and will be implementing it (or another working solution, if one emerges) instead of non-working one. As for passing additional information over FCM/APNS. This data goes totally unencrypted over third party entities, one of which has very little public trust with matters concerning privacy. The mechanics of these services prevent payload from being encrypted, so it's what it is: some meaningful data will go in plain open form over untrusted networks. If we start doing that, why really stop at 'additional data'? We could have saved ourselves tons of blood and sweat spent at making iOS client wake up on notification, connect to a server, fetch recent messages, check their markers and present only an actual message to users, all of this in fewer than 30 seconds. Instead, we could have just displayed banner with a message in a standard open way, without even establishing a connection, and all we had to do is agree to send message contents to Apple/Google. No big deal, right? While I'm not at all jumping on this full e2ee & full stanza encryption bandwagon, compromising user privacy this way is a no go for us. > In the mean while it can present the screen for allowing the user to > accept the call. As soon as the slow human user then presses 'accept' > you're immediately good to go and fully establish the call. This saves > several round-trips, and thus many centiseconds compared to XEP-0353 in > its current form, and even more if you have a model that relies on > re-establishing the XMPP connection before starting all of the above. Of course, it is faster and simpler to do it this way! But at what cost? Agan, If we start developing the fastest solution, we'll eventually come up with some CA service that manages calls directly, fully bypassing XMPP. Is that what we want? -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
