Hacker News Reader

Comment by kagenouta | Hacker News Reader

I, for one, have a bigger problem with it forcing the use of phone numbers as a sign-in method. They're an arbitrary identifier from a legacy system that there's not really a point in continuing to extend, because if your device is capable of anything more advanced than SMS it's also capable of... well, this.

Also KaiOS and the like are making chat feasible even on feature phones.

Don't get me wrong, RCS will be a fine enough fallback (once it's E2E), but standardized chat is the dream.

View on HN

> Don't get me wrong, RCS will be a fine enough fallback (once it's E2E), but standardized chat is the dream.

Is there a plan for RCS to be E2E? Given that RCS went under the GSMA umbrella in 2008, and it's 2020 and adoption is minimal, I don't have any hopes for a future update that supports E2E to come out any time sooner than 2040, with handsets supporting it in 2050, and all endpoints supporting it in 2065; Google will have released about 30 more messangers by then, of course.

Google's working on it, apparently.

Not within the spec. Which was sort of the point I was (poorly) trying to make - that it's a huge caveat, but otherwise a decent fallback if and when that changes.

Google is adding an implementation into Messages, and it's honestly not a critical problem if OS vendors are supporting it at that level, but there's still too much we don't know about it imo. Will that be supported by iOS, if and when it supports RCS at all? Will it work for third-party clients, if and when Android gets APIs?

I'm not sure how much optimism I have that this will be anything other than a fragmented mess in the short term.

The only thing getting RCS any real traction is Google seems to be pushing it in their SMS application, and is now running an RCS server for everyone (or something).

Which basically means, instead of having a federated mess as designed to replace the federated mess of SMS and MMS, we'll get a Google mess, maybe. But if Google was any good at making messenger apps, maybe enough people would use one of them that it wouldn't be killed.

Which just sort of loops back to how if Web-based chat had a spec with meaningful user traction we wouldn't have any real use for RCS in the first place.

Also how XMPP could have been that spec, if Google hadn't decided when launching (the first version of) Hangouts to go full Ayn Rand while doing it.

Tackling this point separately: the entire reason they do this is because they routinely experiment with side projects and then build the ideas that work well into the services that gain traction. As much as it comes with the drawback of being scattershot in general, it specifically creates a track record for failure with messaging because successful messaging products, as a rule, have network effect - something you can't build when you're playing with three different approaches simultaneously.

For an example of where this works really well, look at how all of their adaptive UI efforts feed into each other:

* The enhancements to multiwindow that were built for foldables became Android's desktop mode, to the point that it was built specifically as a test environment and now underpins DeX etc

* Desktop mode's only hardware requirement is a display output, suggesting in addition that Android apps as a whole are no longer bound to specific 1:1 relationships of UI and form factor. (This is, imo, a much bigger deal than we're making it out to be, and opens up possibilities ranging from hybrid game consoles to mobile content creation to better takes at mobile-powered VR.)

* The existence of a base OS implementation and the fact that it's controlled by the system launcher, a component the user can rip and replace, pretty much ensures that custom ROM communities are already toying with this

* Android supports PWAs - installable, natively-scalable webapps - meaning that when desktop mode inevitably stops being feature-flagged there will be examples of convergent apps that work on day 1

* Desktop support for Android apps enhances those same apps when used on ChromeOS

* Flutter, the toolkit built for Fuchsia - an OS designed from the ground up with this sort of scalability in mind - is capable of targeting all of the above

>As much as it comes with the drawback of being scattershot in general, it specifically creates a track record for failure with messaging because successful messaging products, as a rule, have network effect - something you can't build when you're playing with three different approaches simultaneously.

I think what Google needs to do is to seperate the messaging protocol from the messaging software. The protocol needs network effects. The software doesn't. That's why shutting down Google Inbox didn't kill email and it's why any new experiments with email software can benefit from the network effects that email protocols already have.

Hard agree. I'd also argue that any meaningful antitrust action we may eventually impose on big tech companies should force this.

If the one thing so far that's led the feds to threaten this is that they wanted to build a modern protocol for cross-service messaging, then there's no sane reason we couldn't have asked for that exact thing as a spec.

"even on feature phones"? It was perfectly possible at least back in the early 2000's. Where I'm from, we've gone through a lot of different IMs over the years, including XMPP (which I was a big fan of, but started to despise because it had such terrible support for mobile clients). Many J2ME clients had pretty advanced features like group chats and file transfers.

conversations.im is an excellent android client for xmpp.

Huh, TIL.

Reply on news.ycombinator.com