> GO: windows has become terrible for developers and this AI focus makes it worse
> PD: we listen to feedback, people want reliability etc. we care deeply about developers. we know we have to improve on [things which you didn't bring up at all]. we will continue improving.
... I honestly don't think I need to explain why they got ratio'd.
> windows has become terrible for developers and this AI focus makes it worse
Except it's not totally terrible. What makes it terrible is the privacy invasions and the consent issues Microsoft has with its users, along with long standing bugs in W11.
The other hand of Microsoft is actually putting a lot of convenient stuff in for developers. WSL w/ graphics support, Windows Terminal is nice (and is getting some nice features they just showed off at ignite), native git integration is coming to file explorer, PowerToys has some really great utilities, and making your own extensions for command palette is dead easy.
There's even a macOS preview-like utility for file explorer now, sudo, native SSH, winget (which can be automated with a simple yaml file to automate a new box setup using DSC), etc.
It's the classic Microsoft org chart problem where each is in their own bubble pointing guns at each other.
Windows could objectively be the best OS for developers, easily, if Microsoft cared enough to make it so. Their surface hardware isn't bad either, and the surface laptop is the only windows laptop on the market with a trackpad that's anywhere close to Apple's.
That's what makes Microsoft so frustrating lately. I used to like Windows, I want to like it and use it again, but Microsoft keeps shooting themselves in the foot over and over again, screwing everyone over in the process.
I've had constant problems with the verification ever since it was introduced. As far as I can tell it hasn't improved at all. Sometimes it works, sometimes it repeatedly kicks me out moments after succeeding, and it's still prompting me to verify some old devices that I removed Element from years ago and I can't find any way to make the constant pop-ups go away (when they feel like appearing again - sometimes they go away for a couple months).
By spec E2EE (via MLS, or something extremely similar) is in fact the default - it's part of the Universal Profile, at least as of 3.0 which I have been reading.
Is Google following that with Google Messages? We have no way to verify! How great for everyone.
And this is what I find so galling, it took them to version 3.0 to decide to do that?
My quick googling shows:
v1: 2016
v2: 2017
v3: 2025
So, yes "by default" in the current year it supports it but no one (including google) is using 3.0 yet. Apple has pledged to do it in iOS 26 (currently using 2.4) and Google has some proprietary e2ee on top of 2.6.
It's just all a mess, the furthest thing possible from an "open standard" (not saying anyone claimed it was, that's just what I would have prefered if we were trying to replace SMS/MMS), and hopelessly behind all other messaging platforms.
I was curious about the adoption timeline actually, yeah - hadn't looked at that in detail yet. Thanks!
How wonderful that they've been claiming better security all along too. (it may be true, sms is terrible - but they know many people will think E2EE or similar when they hear that)
Yeah... I just started getting back into building sms/mms/rcs apps on Android and oh boy. It's much more of a mess than I expected, and much more "oh so it's basically just Google now, and they seem to be trying to lock it down further" than I expected (or hoped).
And you can't even implement it yourself because it requires special permissions on Android, which you can only get if you're a carrier/oem-blessed app. And the early "you'll be able to build other apps, there will be an API like this: https://github.com/android-rcs/rcsjta" promises (which would put it on par with sms/mms) never materialized, despite a reference implementation that did exactly that over a decade ago.
At this point I'm just totally against RCS and I'm intentionally turning it off. Why hand all of your messaging communications over to Google, when they've got such a consistent history of being hostile? We're much better off going back to telling people not to use sms (or mms or rcs) at all because it's insecure.
> And you can't even implement it yourself because it requires special permissions on Android
That depends on your carrier, which is even worse. There are several ways to activate RCS for a phone number, as this standard is meant for carriers rather than app developers, and the carrier gets to choose which one they want.
I think the reference implementation died around the time carriers shut down their RCS servers because nobody was using them. https://github.com/Hirohumi/rust-rcs-client seems to be the most reason open RCS client at the moment (with an Android demo app).
The real need and opportunity for an RCS messenger is on the LineageOS/custom ROM scene, where these permissions are available (you can sign the ROM yourself, after all).
As for the Google stuff, RCS being routed through Google is an anomaly that will hopefully be fixed as carriers add support to it so native Android <-> iOS messaging isn't completely terrible. Progress has been slow outside of countries that still use SMS (like the USA) but eventually we'll be back to normal carrier-based carrier message exchange once things calm down a bit.
On the Android side of things, I don't expect things to change soon, as most of the restricted fields were at one point available to developers and were mostly used to stalk users across installs without their knowledge for tracking and "telemetry" purposes. A country where people actually use SMS/RCS will have to crack down on Google's lack of an RCS API.
The problem with all these problems is that it makes RCS noticeably worse in both normal use and for your privacy than a regular web chat via some other system. And I do not see a path for it that escapes that.
I'm very happy that they're essentially using MLS, that's a real benefit[1]. But other chat apps can (and some do) do that too, without actively driving every single carrier globally to give Google all of your messaging activity. We're better off having diversity.
This all could reverse course and become acceptable, but I don't see how it would happen in practice. It seems much more likely that everyone will just give up and say "yeah that didn't work".
1: Though without alternate impls they can just silently MITM it and how would you know? RCS users: have you ever verified your messaging keys out of band? Do you know how? I can't find it in Messages. The "Universal Profile https://www.gsma.com/solutions-and-impact/technologies/netwo..." for RCS that describes a ton of things compliant apps have to do (many of which Google Messages does not seem to do, as far as I can tell) has no instructions at all to show users their keys or provide a common way to verify them (as far as I can tell). Client diversity provides a way to detect some attacks here, but there is currently almost no client diversity, and instead it seems to be shrinking towards just Google Messages, using Google's servers.
^ They are correct, the MLS / E2EE part of RCS is quite new and not yet implemented ~anywhere. So it gets no points until widespread, and this is now a decade after RCS's introduction. I think we can expect it to take a long time yet, if at all.
> eventually we'll be back to normal carrier-based carrier message
Why would you want to go into this closed model, where you’ll likely be charged per-account? How is this any better than XMPP, email, or any other IM protocol out there?
> generally included in the plan you pay anyway for data access.
Er, what? The main reason why most of the world moved from SMS to internet-based messaging is because SMS was far more expensive.
> having it for emergencies is nice
In what kind of emergency could SMS be useful?
> just to bootstrap an alternative, secure channel.
But you need to exchange SMS numbers to do that. You might just as well exchange emails, XMPP, or whatever other protocol your going to use later and skip SMS entirely.
Because SMS is horribly limited. 140 chars per message* (less if chars are not plain vanilla ASCII), no support for attachments, group messages, reliable delivery receipts, emoji reactions, etc etc.
* There's a terrible hack called concatenated SMS that strings together multiple messages to build one longer message under the hood, but if any of those parts go missing along the way, the whole thing gets dropped on the floor.
For the proposed use case, you don't need those things, except maybe the 140 character thing, but I've never found that limiting, since phones stitch them together nowadays (and have for the past 15 years?).
Sure, RCS has those functions, but half of them are broken 60% of the time, and you don't need those anyway for bootstraping into wherever you actually want to talk, and for short messaging.
RCS brings nothing to the table if all you need is to tell mum she needs to come pick you up. On the contrary, it might fail you because it tried and failed to send that message over a 4G connection you barely have, rather than sending it as an SMS and then actually arriving. And you're never going to use it for group messages, attachments or with emojis unless its an actual service you intend to use for serious purposes, which is exactly what the comment I was responding to said you weren't going to use RCS for anyway.
I disabled RCS (and iMessage back when I had an iPhone) for exactly these reasons, but still use SMS as a fallback with people I don't actually know and never intend to talk to again, and see no reason to upgrade to RCS even if it wasn't broken, since for my use cases, the extra feature set isn't needed. If I need more fancy features, its for use with people I actually know, and thus people I can get in touch with on not-SMS.
Mostly because my understanding is that RCS is meant to be a drop-in replacement for SMS and if you’re on a device that supports it (or your carrier-specific configuration of RCS) you don’t actually have a choice and your “SMS” is actually RCS and you must use it and hope it works.
Given that there's a 'Disable RCS' toggle (and a 'Resend as SMS' toggle for that matter) that seems to re-enable SMS and eliminate the RCS weirdness, this doesn't really seem to be true. I guess it could be in the future when carriers disable whatever path SMSes are currently going through, leaving you only with RCS that might still be borked.
I'm not entirely sure what you're claiming here, but broadly speaking no, this is not correct.
RCS is, by spec and in practice, intended to fall back to sms/mms if it doesn't work for some reason (e.g. you're roaming and not connected to your carrier. or have opted out. or they're having an outage. or...).
And there's an opt-out (partly because it kinda requires syncing your contacts to the RCS servers... technically only for "online presence" and for any individual you contact to check their RCS status (which is completely reasonable) but do you know where that presence toggle is in Google Messages? I don't).
The fallback is not really automatic or anything, RCS's feature-set is gigantic and allows senders to have far more control over the message's presentation (https://developers.google.com/business-communications/rcs-bu... currently has visual examples of this). It's rather clearly a "built for businesses" system, at least in part. But "RCS might not be available" is very much a core expectation for the stacks as a whole - the world is a big place, and there are many old phones and out of date apps, even if every carrier gets on board. (this is very likely one of the reasons why everyone's just piling into Google's stuff)
If they ever get things working, they might try to force it everywhere, but that's probably like a decade or three away at a minimum. Accurately predicting industry and legal trends on that kind of horizon is basically impossible. They might be planning on it (I have no evidence either way), but achieving is an entirely different matter.
My novice read of it is that Google made the mistake of trying to hand off the management burden to carriers, since they felt that the way to make something universal like SMS/MMS is to include carrier support.
But that obviously didn’t work because there are hundreds (thousands?) of cellular carriers around the world and they are the wrong people to manage such a thing.
So they basically are steering it back to “Google’s shitty iMessage.”
The universal thing isn’t the carrier anymore, the universal thing is the Internet that runs on top of it, which is perhaps why just about everyone outside the US tends to use messaging apps like WhatsApp/Signal/WeChat/etc.
It turns out that the only thing worse than the platform monopolist was the old phone carries monopolies.
> just about everyone outside the US tends to use messaging apps like WhatsApp/Signal/WeChat/etc.
This is The Way. Well, several ways, since you inevitably end up a bit fragmented, but usually a country will settle on one, usually WhatsApp. Further east Telegram is also popular.
...and then WhatsApp starts to send ads in push-notifications that you can't turn off. And you either have to live with it, or be a massive black hole in your friends communities.
I don't know if RCS is the way, but monopolistic messaging apps definitely aren't.
> and then WhatsApp starts to send ads in push-notifications that you can't turn off
*that you can't filter.
Every time an app begs me to enable notifications, I give it the side-eye because I immediately assume it's going to include notifications that I don't want to see, which are essentially ads for some app feature / some part of their walled garden.
I want to be able to filter notifications at the OS level. That could be by a substring search on the content of the notification, or by a unique-per-call-site (in the code) identifier included in the API the app uses to surface a notification (though I suspect most apps would just re-use the same identifier everywhere because the developers don't want me to be able to filter their ads).
> My novice read of it is that Google made the mistake of trying to hand off the management burden to carriers, since they felt that the way to make something universal like SMS/MMS is to include carrier support.
I'm not sure who you are calling "carriers", but it sounds like the people who own a mobile network. They buy gear off a supplier like Nokia / Huawei, contract them to install and maintain it, then make their money back over time by selling the bandwidth to consumers and hopefully a "free" phone as well.
They aren't the engineering power houses the telco's of old were, like AT&T. Rather they are reverse - a marketing powerhouse, duking it out with other marketing power houses. Their technical know how is close to 0. In fact on the retail support side, it might even be negative. When I deal with them, I come away with the impression would have trouble fixing a propelling pencil. If Google thought they could manage a massively parallel e2e messaging stack, they were deluding themselves.
This is the real reason Huawei was banned by the West. It wasn't just that it meant they were using Chinese make the gear, with opaque Chinese firmware, although I guess that was bad enough. It was that if the telco's bought Huawei, Huawei ran it for them. "Ran" means hands on, 24 hours a day, with in Huawei engineers deployed around the country keeping it ticking. Having a Chinese company running your countries mobile phone infrastructure was an impossible swallow.
Every time I have gotten a SIM card in a country south of the US-Mexico border, the carrier spams the text messaging. But nobody else uses it.
In the US we don't reliably use WhatsApp, iMessage is locked down, and Signal, etc., are just for tech bros or political hacks. Yet, everyone wants to text instead of call, so we are in this world where we need to make RCS work, and they are just not putting in the effort.
What I mean is that in Mexico, Brazil, and many other countries, WhatsApp is the de facto messaging standard. Businesses expect you to have it, restaurant ordering is integrated with it, etc.
Yeah. I'm as frustrated as you are. I had an app in the app store even with all the restrictions around SMS, but there's simply no way to integrate with RCS, so this is basically Google's iMessage.
+1. I was a strong proponent of RCS earlier. Don't care about Green/Blue bubble nonsense. But Google (an Ad company) started abusing RCS to send garbage ads my way. And there is no way to block that as well except for disabling RCS. I feel this is a loophole Google can abuse where local regulations ban vendors for sending promotional messages.
Whatever it is, Google of all org should not be at the Helm of this.
And the amount of moral policing they did to apple. Disgusting assholes. I hate Apple for a lot of reasons. iMessage is definitely not one of them.
I know this is a niche complaint but I hate packaging golang things. On Gentoo contributors are stuck hosting giant dependency tarballs since you need the modules to build a package and we sandbox networking while building.
I definitely think people will regret adopting Golang in time. It's this generation's Java, except without an smooth off-ramp in Kotlin/Scala and even less of the benefits.
In some countries, Whatsapp is pretty much the de facto town square. Friend groups, family groups, event planning, customer support for businesses (though now it's just talking to shitty AI bots), all on WhatsApp. You can't beat the network effects any more. One understands why Meta paid 19b for it.
Our IT department has found a way. Want to get some credentials sent to you (usually just for new accounts)? They send it only via Signal as a out of band method.
This turned Signal into the defacto default in our org.
Signal does some things well, but lacks far behind other apps in UX. It doesn't do cloud backups either, which keeps me from recommending it to less technical folks.
Only in the Beta Android app for now... Signal is around for what, a decade now? And they still can't (or rather, refuse to) do the basic "copy the SQLite DB file to a folder". Edit: and even this beta feature is some bullshit proprietary thing with their own cloud and subscription rather than simply "let me export the DB file and stick it in a cloud provider of my choice".
Last time I had to reinstall my phone I ended up finding an implementation of their phone-to-phone transfer protocol to emulate a "new" device I'm transferring to just to get a dump of the data (I'd share, but don't want them to close this option, since clearly the lack of export option is very much intentional).
Then I deleted Signal and begrudgingly moved to WhatsApp (in addition to iMessage which I've already been using).
Never on iOS or any other Apple platform. Signal is designed not to be able to backup to iCloud either. The only option iOS users have had over the last few years is to do a device to device transfer where both phones are expected to be in physical proximity and it takes hours to transfer the data. Lost phone has meant losing all chats.
WhatsApp, which is infamous by association with Meta, backs up to Google Drive or wherever.
> Telegram, for all its faults, has an excellent desktop app.
Their developers are also very responsive to PR's, I have a couple GCC build fixes in it.
I really soured on Signal early with when running BB10, they would not let us fork and use/distribute websocket builds to get around not having google play services on available on that platform: https://github.com/libresignal/libresignal/issues/37#issueco...
I'm still a little sour on it now because there's still no way to transfer the identity since they refuse itunes/icloud backup, refuse any way to export a key, and I have to look at hideous corporate memphis icons every time I set up Signal new again on iOS (at least Android doesn't have the last thing).
I mentioned before, but I use mautrix-signal to be able to have a unified (except for telegram) messenger on desktop with nheko or element via matrix. It works really well.
> Why hand all of your messaging communications over to Google, when they've got such a consistent history of being hostile?
The alternative is to hand all your communications to carriers, who have a consistent history of being incompetent, extortionate and bending over to authorities to disclose everything you've ever said at the drop of a hat. Exhibit A is SMS, which is totally unencrypted, plagued by bad actors, and a cesspool of spam and fraud.
In an ideal world you could choose who does your RCS, in the same way that you can pick your email provider, but the way it's baked into the telco ecosystem makes this basically impossible.
But it is absolutely nowhere near as polished a user experience as Pebble was. I have had constant disconnects for months at a time with Gadgetbridge, loads of edge-case bug-like behavior that is in fact documented but in a weird location that nobody would look at or consider reasonable behavior, three hardware failures in three years (I'm still using one of them with a busted vibration motor), and on-device UX and tap accuracy and freezing that really only works out if you're sold on everything else about the device.
I haven't found anything else I'd recommend for a Pebble fan though, it really is the closest. I'm begrudgingly happy with it because I have no better alternative, not because it's an actually-good product.
I really think all permissions systems need what we had back in xposed/appops days:
Permissions should ~always be "accept (with optional filters)", "deny", and "lie". If the game wants contacts access and won't take no for an answer, I should be able to feed it a lie: empty and/or fake and/or sandboxed data. It's my phone and my data, not the app's.
We had it over a decade ago, xposed supported filtered and fake data for many permissions. It's strictly user-hostile that Android itself doesn't have this capability.
browsers are really not much better. on an absolute level, I definitely agree they're better (e.g. they have per-url and only-after-click permissions for some things), but they've all got huge gaps still once you start touching extensions. and beyond that it remains to be seen, since OS-level permissions are significantly broader-possibility than in-browser due to being able to touch far more sensitive data.
yes, they're admitting that their APIs are powerful enough to build accessibility tools (which often must read notifications) and many other useful things (e.g. Pushbullet) that are not possible on iOS.
powerful stuff has room for abuse. I didn't really think there's much of a way to make that not the case. it's especially true for anything that you grant accessibility-level access to, and "you cannot build accessibility tools" is a terrible trade-off.
(personally I think there's some room for options with taint analysis and allowing "can read notifications = no internet" style rules, but anything capable enough will also be complex enough to be a problem)
You may be overthinking it. Verification of some sort isn’t the end of the world, it’s arguably an acceptable damage control stop-gap that has precedent on other platforms like special entitlements on iOS and kernel extensions on Windows.
Googles proposal was to require everyone to verify to publish any app through any channel. That would be the equivalent of a web browser enforcing a whitelist of websites, because one scam site asked for access to something bad.
If scam apps use an API designed by Google to steal user data, then they should fix that, without throwing the baby out with the bathwater.
I mean the solution really is a comprehensive permissions system, for an accessibility system that needs to read notifications you should be able to deny it network permissions and whitelist which app's notifications it's allowed to read
entirely agreed, but in the context of this thread that means you just have to convince someone to enable it for the one app, rather than the phone as a whole. which doesn't seem to help at all with the coercion scenario (if anything that might make it safer-sounding and therefore easier), just under normal use / to limit possibly-malicious apps.
> GO: windows has become terrible for developers and this AI focus makes it worse
> PD: we listen to feedback, people want reliability etc. we care deeply about developers. we know we have to improve on [things which you didn't bring up at all]. we will continue improving.
... I honestly don't think I need to explain why they got ratio'd.
reply