I don't know that RyanZAG is so much being user-hostile as reminding us that there are facts of non-free systems that are going translate to user-hostile for at least some subset of users.

There's incentives for people who make closed systems to make the most common edges of them comfortable. There's also incentives for them to ignore other sharp edges or to even actively make other edges nearly untraversable.

I came here to say exactly this. Source: I work in the guts of some of the biggest telecom networks on the planet.

Federation is a problem because none of the standards interop. The closest thing we had was XMPP which became mega-bloatware as time went by and is now just not something anyone wants to implement (and it's becoming less of an issue as most of the players move away from open-ness).

While the technical among us understand the ramifications of these decisions, the silent majority do not. I believe it was Elad Gil who said that services that eschew privacy have historically dominated their more private opponents. Users say they care about privacy but their explicit value systems (what they say versus what they do) says otherwise. The majority of consumers are happy to take iMessage and use it to the extreme and will attribute silent failures to the operators in most cases (which is not necessarily wrong).

True federated identity is the death of the phone network and there are just too many billions of dollars tied up in the world for this to come to pass. A phone number is a ridiculously arbitrary identifier for a person, and yet it works and has worked for quite some time. Logically addressed networks are finally starting to break, and that's a good thing, but the catalyst that will move us away from these systems is one that subsumes existing infrastructure while adding new features. You cannot rip and replace our communications networks (or any infrastructure for that matter) and so the only logical solution is to subsume. It's not easy, but that's how this gets fixed.

It's almost absurd the lack of fanfare surrounding AT&Ts proposed phase out of the PSTN in favor of IP networks.

We got number portability and wireless number portability, but the carriers still act as if they own our e.164 addresses and make the transfers arbitrarily difficult. We use phone numbers of SMS, but really we use individual address books, stored in devices, or synchronized with central repositories. We use names to identify people and have to work hard to ensure that our address books are not filled up with duplicates created because we used a one-off email address, or phone number and the phone wasn't able to merge it with an existing contact automatically. We have identity providers that can only represent a small portion of our identity, real names on Facebook and Google+, but cannot resolve that back to our phone numbers or find the best way to contact us at any given time. Presence, which was the real promise of IM and XMPP (and SIMPLE if you must) is not integrated. I cannot determine before hand whether somebody is available to talk on the phone, would prefer a text message, or if I should leave a push voice message they can listen to at their leisure.

Even calling a company with a well designed IVR is still a confusing waste of time, when the device I am calling that system from is smart enough to contain any identifier or proof of identity that the called party would need, the protocols are artificially limited to phone numbers as identifiers. There is also no out of band solution to this problem, or the the problem of selecting what department I would prefer to speak with about a problem without navigating a menu that the interface on my device is not really designed to use. Think DTMF on an Android device where the screen shuts off.

Um. I'm not the one who made iMessage - you need to look at the guys making locked down messaging systems for the user-hostile actions causing problems like these and no doubt much more in the future. If I could help these people out and give them a script to run to fix their problem I would - but of course I can't, because everything is locked down by others who are putting their own vendor lock-in above user satisfaction. And I agree that it is the biggest problem in our industry.

You don't do a good job of envangelising for open source and open standards by making posts like the 2 in this thread.

I disagree, I think he made excellent points, and I fail to see why you think there is a problem with his comments.

You're focusing on lock-in at the client level. And while I agree that's a problem, it's not the biggest problem. Not by a long-shot.

It is the biggest problem, it's just hard to see. Let's assume iMessage was OSS and freely uninstallable/re-installable on iOS devices. This would mean that an iMessage fork could be created that was able to talk to additional services and not only Apple ones. This would be done quickly as iOS users would want to use iMessage to talk to Android users also. The iMessage client itself would be duplicated for Android quickly as well if it was OSS.

As most users would prefer the Android compatible version, the forked version would likely be installed by most users as most users would want to talk to Android. This problem would then be easily fixed: someone could just submit a pull request for a fix for this issue and create a way to easily stop receiving messages through iMessage. Even better, the author would not need to stop using iMessage - he could keep using it and receiving messages on Android.

Ultimately removing the lock-in at the client level forces the problem to auto correct itself across the board by allowing users the option of migration and developers the option of improvement.

Thinking about it further, I don't even think it's appropriate to call this "lock-in".

I very much doubt the Apple engineers who wrote iMessage were rubbing their hands together in maniacal glee, at the prospect of being able to prevent people from ever migrating away from iOS, if they but used the phone number in this specific way.

It sounds like it's exactly what TFA's author assumes: a bug.

Sufficiently advanced incompetence is distinguishable from malice.

Apple has certain well advertised priorities. Interoperability with non-Apple systems is not one of them.

(Not to blame Apple in particular -- non-intropability is coincidentally a common feature among the biggest player in every industry, while interopability is a key feature of challengers. But it's just a "bug"... )

Does it change much to focus on the original intention of the engineers?

If the bug ever surfaced or was ever thought of by anyone at Apple at any point in the development process of iMessage, Apple will have effectively accepted to lock the user in by not having it fixed or communicate about it in some way.

The OP must not be the first to report the problem either (he switched after iOS7, iMesssage was more almost two years old by then) ?

This might not be an issue Apple cares in any way, and that's fine for them. We should just recognize their shitty behavior, even if it's originally accidental.