Google Is 'Pausing' Work On Allo In Favor 'Chat,' An RCS-Based Messaging Standard (theverge.com)

An anonymous reader shares an exclusive report from The Verge about Google's next big fix for Android's messaging mess: Instead of bringing a better app to the table, it's trying to change the rules of the texting game, on a global scale. Google has been quietly corralling every major cellphone carrier on the planet into adopting technology to replace SMS. It's going to be called "Chat," and it's based on a standard called the "Universal Profile for Rich Communication Services." SMS is the default that everybody has to fall back to, and so Google's goal is to make that default texting experience on an Android phone as good as other modern messaging apps. As part of that effort, Google says it's "pausing" work on its most recent entry into the messaging space, Allo. It's the sort of "pause" that involves transferring almost the entire team off the project and putting all its resources into another app, Android Messages. Google won't build the iMessage clone that Android fans have clamored for, but it seems to have cajoled the carriers into doing it for them. In order to have some kind of victory in messaging, Google first had to admit defeat. Some of the new features associated with Chat include read receipts, typing indicators, full-resolution images and video, and group texts. It's important to keep in mind that it's a carrier-based service, not a Google service. It won't be end-to-end encrypted, and it will follow the same legal intercept standards. The new Chat services will be switched on in the near future, but ultimately carriers will dictate exactly when Chat will go live. Also, you may be persuaded to upgrade your data plan since Chat messages will be sent with your data plan instead of your SMS plan.

Comments

Nope ...

[Anonymous Coward]

Don't have a data plan, don't want a data plan.

Fuck you and your data plan, you better keep supporting SMS, because it's not going anywhere.

SMS will stick around

[Comboman]

Since SMS is baked into the cellphone signaling protocol (and is the last thing still working in an emergency when data and voice are overloaded), I suspect it will be sticking around for a while.

Re:Because using standards is so 2000 & late

[jouassou]

This. I've recently gone through a phase where I've been trying to get monopolies and clouds out of my life myself. If you need any inspiration, this is what I've ended up with:

• * KolabNow as an email provider instead of GMail. They have a good privacy policy, are hosted in Switzerland which has fair privacy laws, and costs about $3/month.
• * Syncthing for making your own open-source "cloud storage" as a replacement for Dropbox and Google Drive. I've played around with a few alternatives, but this was my favourite; it's very straight-forward to set up, fully peer-to-peer so you don't need a centralized server if you don't want one, and it has clients for most operating systems. The Android app lets you set it to only sync when it's on WiFi and/or charging.
• * Maps is an alternative to Google Maps, which uses OpenStreetMaps, the "Wikipedia of navigation". It doesn't have the same knowledge of local shops and restaurants as Google Maps does, but it is "good enough" for most of my needs, and in contrast to other clients like OsmAnd, the interface is actually quite slick.
• * CopperheadOS for my phone. It's still partially in the Google ecosystem, by being an Android distribution that requires a Nexus or Pixel. But Android itself is still mostly open-source, and this comes with all Google apps and services stripped out. (Lineage works as well, but Copperhead is more focused on privacy and security.)
• * Yalp. Some apps are simply not available outside Google Store (e.g. online banking apps in my case); this helps you install such apps without having to install the full Google Services platform on your phone.
• * Firefox Focus/Klar. In contrast to the usual Firefox browser, this new app is actually useable on a phone; and last time I checked it had better privacy settings than the Chrome browsers you find on most androids.

Re:Why does it need to be carrier based?

[TheRaven64]

The problem with XMPP is fragmentation. The core protocol is an IETF standard, but it's very minimal (messages, presence notifications, basically nothing else, including how clients authenticate with servers). Everything else is handled via XEPs and for every feature there are 3-4 XEPs describing incompatible ways of providing it. Google did a pretty good job with Jingle, which provided file transfer and a way of setting up streams to use for video / voice, but clients all implement different file transfer mechanisms. I don't think I found a single pair of Android XMPP clients that could exchange files, for example. There are multiple mechanisms for publishing avatars. The last time I looked, the most widely supported one was vcard-temp, which involves setting an base64-encoded image in an XML encoding of a vcard that you publish inside your presence stanzas. This XEP was deprecated as soon as it was published because it had a bunch of well-known problems and was intended as a temporary stop-gap. The replacement was built on top of PEP (personal eventing via PubSub) which was, in turn, built on top of PubSub. The PubSub XEP is fiendishly complicated to implement and PEP adds even more complexity, so it was years between the standard being published and any clients or servers properly supporting it.

This last point really highlights the problem with the XMPP standards process. The IETF requires two interoperable implementations for an RFC to advance. The XMPP Foundation happily publishes standards-track XEPs with zero implementations. They never produced a reference implementation of a client library. Some newer open IM standards have learned from this mistake. For example, Tox provides a client library that is used by multiple clients and serves as a reference implementation. Unfortunately, it's not GPLv3, so anyone wanting to implement a non-GPL Tox client must reimplement the protocol (it's still better than no reference implementation though, and providing an incentive to implement a second client library may be good for the protocol in the long term).