Re: [Standards] XMPP OAuth2 login at Google
That’s a relief. I noticed you did this in the newer Adium betas and was wondering what was going on. I guess it’s on my radar to complete on Monal now as well. The gradual movement away from standard XMPP in gtalk is depressing. -Anu On Apr 20, 2015, at 10:01 AM, Thijs Alkemade th...@xnyhps.nl wrote: On 20 apr. 2015, at 10:15, Thijs Alkemade th...@xnyhps.nl wrote: [Reviving a very old thread] It looks like today is going to be the day Google shuts down ClientLogin [1], and with that, SASL PLAIN [2]. This might be the final nail in the coffin of XMPP support for Google Talk, as I fear few clients have implemented X-OAUTH2. We have an update in beta for Adium, but working on that while knowing Google could shut down the XMPP interface any day was not very motivating. Thijs [1] = https://developers.google.com/identity/protocols/AuthForInstalledApps [2] = http://googledevelopers.blogspot.com/2012/09/adding-oauth-20-support-for-imapsmtp.html False alarm, apparently, in last February they made a new post [1] stating: We’ve taken steps to provide alternatives to password authentication in other protocols as well. CalDAV API V2 only supports OAuth 2.0, and we’ve added OAuth 2.0 support to IMAP, SMTP, and XMPP. While a deprecation timeline for password authentication in these protocols hasn’t been announced yet, developers are strongly encouraged to move to OAuth 2.0.” Thijs [1] = http://googledevelopers.blogspot.com/2015/02/reminder-clientlogin-shutdown-scheduled.html signature.asc Description: Message signed with OpenPGP using GPGMail
[Standards] Proposed XMPP Extension: Push
Hi all, I make an XMPP app on iOS called Monal. Much of my comments are based on my experiences developing an XMPP client on iOS for the past 6 years. My concerns may be Apple specific in some places but since the intent of the XEP is for a very general implementation, these issues should be considered. Apologies for resurrecting this discussion. The proposed XEP does not seem to address token expiration. On Apple platforms (and likely others) the push token will change periodically. This information is provided on a feedback channel to the App server but there is no way for it to communicate this to the XMPP server. There is really no way for the client to know it’s token has expired so It will not know to request a new one from the push service and the messages will just be lost. In addition even if the client were to somehow know, there doesn't seem to be a way for the client to refresh its token with the XMPP server. It may also be nice if the client could define what events it cared about. Most mobile clients are probably not going to care much about anything other than ping and message stanzas when operating in the background. There would be significant battery life improvements if a client could take advantage of XEP-0198 (with a very long expiration) to close the socket unless a message or ping arrived. While XEP-0198 is probably beyond the scope of this document, it’s probably how I and others will try to use push, so it may warrant mentioning. Thanks, -Anu
