Just think, if you hadn't used a proprietary messaging solution as your default contact method, you'd be able to easily control how you receive the messages. Maybe stuff like this happening is a good thing as it drills home the point the 'crazy free software lunatics' have been going on about for some time. Having this kind of thing happen to someone makes the stuff FSF+co says a bit more relevant and ultimately helps everyone.
> Just think, if you hadn't used a proprietary messaging solution as your default contact method, you'd be able to easily control how you receive the messages.
Apparently blaming the victim is totally okay as long as the victim was using a brand you don't like.
You've failed to understand on two levels. One, this is not a question of competing brands. That's a question of technology and not liberty, which is the point of the comment you replied to; if OP choose free software, it doesn't matter which "brand" he chose, there are a number of free application that do the same job.
Two, calling this victim blaming is a bit of a stretch at best and ridiculous nonsense at worst. Yes, what happened to OP is unfortunate but it's just a moderate inconvenience. It's not like someone drove their car over him or smashed his face in with a bat (he'll get over this much easier). The person you replied to therefore is not wishing serious ill will on him. They are simply saying they hope this mild inconvenience is enough to wake him (and others) up to the necessity of free software.
>One, this is not a question of competing brands. That's a question of technology and not liberty, which is the point of the comment you replied to; if OP choose free software, it doesn't matter which "brand" he chose, there are a number of free application that do the same job.
I call BS. If OP choose free software we could AS WELL have had the same exact problem.
It's a software bug -- the client caching the remote method to use (data or standard SMS). A free program could just as well have the same issue.
What "more control" you'd have? You could issue a bug fix request, which could just as well be ignored (I've several on FOSS projets). Or you could even have it fixed, but then you'd need to convince all the users you talk to to update to the latest version until you see any improvement.
If it was an open protocol, he would have access to apps that implement it on his phone. And even if that weren't the case, he would have the ability to write an implementation.
The difference here is that a sufficiently competent person cannot reliably replicate the experience.
The problem at this point is with the other friends and family who make use of this software. Great, he writes a new implementation of this protocol that prevents _his_ client from improperly caching routing information. This still doesn't fix the problem of the software on other peoples' phones.
> They are simply saying they hope this mild inconvenience
If you read the post, you would know this is not a "mild inconvenience" for him. If you truly believe that, then I would contend you haven't experienced what it's like to lose a significant amount of personal data.
> is enough to wake him (and others) up to the necessity of free software.
What free software was he and everyone he's communicated with in the past 5 years supposed to be aware of?
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.
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.
Try switching companies and see how well it works. I have no idea what the actual porting process involves, but then neither did the 2 big telecoms I was dealing with. I had weeks of carrying 2 phones. One received calls, the other SMS. And the telecoms sat there blaming each other. Vodafone and Telecom. New Zealand.
I've gone through number ports in the US three times (seven if you count each number separately) without a single problem. Each was completed within several hours, and dual service time was somewhere between minimal and non-existent (suddenly the old phone stopped and the new phone started). This is in line with what I've heard from friends and relatives, too.
I've read some porting horror stories online over the years. Yours is probably something like the 6th or 7th. I assume things do sometimes break, but it doesn't seem to be particularly frequent, considering millions of people switch carriers every year.
It breaks surprisingly commonly. You've moved 3-7 times in a few years. I move different customers numbers at many times a month. Around 20% of the time we have issues with fail to fast busy for 8 to 12 hours where no system on the telco side takes a call.
I will say this though, switching mobile goes rather well almost all of the time. Porting numbers on fixed telephone lines is much more apt to fail.
If other peoples' misfortunes are influential in keeping others from making bad decisions that have an effect on us all, then yes.
Even the 'good' behavior in this case is awful. Why would a text message fallback to MMS rather than SMS? I'm pretty sure it's because Apple wants non-iPhone users to think of their phones as broken.
>Just think, if you hadn't used a proprietary messaging solution as your default contact method, you'd be able to easily control how you receive the messages.
He would also have lost other benefits, such as convenience, automatically using data instead over SMS for casual chatting, using the method he damn wanted, etc.
What having a problem like this justifies is FIXING the problem, not not using the technology in the first place or some ideas about proprietary and OSS.
Not to mention those are beside the point. Even if he DID use a proprietary messaging solution, he might very well have the same issue. It's not an issue that stems from being proprietary, it's an issue that stems from a stupid caching implementation. If some FOSS mobile chating app had the same bug, he would have been bitten by it just the same.
Depends on what you want to do. I admit I didn't know what iMessage was capable of, but the basic features (text, images) are also possible with XMPP. The more complicated ones is a mixture of "the ISPs don't allow that" (I'm thinking accepting inbound connections), "the user needs 3rd party support" (I'm thinking about needing a proxy server for transfers, which most people don't have, but Apple can conveniently proxy transfer through its own servers) and "just do it".
The problem with XMPP (or any IM protocol for that matter) is that if nobody uses it, there will be little technical progress, which means few people will use it, etc...
Email? Really, now that everyone has email on their phones, why bother with SMS or these SMS-like systems? Email is more reliable, more flexible, and seems to be just as fast in practice.
The smallest email in my inbox right now has 913 bytes of headers and 132 bytes of content. Between the various hops, including through a spam filter, it took 13 seconds just to land on my server. It was then an additional 0 to 300 seconds before each of my devices knew it existed, because push remains black magic when dealing with clients and servers from different authors/companies.
This is not comparable to the normal performance of SMS or iMessages.
Except there is no email app that I know of that presents conversations in way that is as easily readable as line, messenger, etc. I wouldn't want that either as the current presentation is perfect for large amounts of information that I get in my other emails.
The reason iMessage works well is because it's integrated tightly into the OS. So for an open-source alternative to be competitive, it would have to run on... an open mobile OS, which would in turn require open hardware.
Heh? Have you tried solutions like Whatsapp, GroupMe, or Viber? They all work absolutely fine on both big mobile OSes, regardless of hardware.
I don't see the need for absolutely open hardware for an alternative messaging system. Sure, they aren't FLOSS solutions, but they are much less closed than iMessage and are cross-platform.
Fine, but Viber does, right? There are open source, secure messaging systems on the way too. My point was that you do not need open hardware to have a relatively open messaging system. Just look at IRC as an example. It might be somewhat dead now, but it certainly runs on everything now.
Sure, you can use proprietary hardware (iPhone) and try to make it run different software, but your luck getting around their protection systems may vary (and it may or may not be illegal, depending on how much you care).
Curious: has this even been tried? I would assume Apple SoC's require binary drivers, so even though they are similar to Android phones on a hardware level it might be difficult or impossible to even get an Android port to boot.
Hell, it can be difficult to get an unsupported version of Android to work without major bugs on an Android phone.
Important to point out: the authors of iDroid stopped, but not due to any technical obstacle; it was mainly because iDroid was a hobbyist project and their lives intervened. Someone else could pick up the effort today, if they wanted.
However even if someone picked the project up again it wouldn't run on any modern devices, since the last iPhone to have an untethered bootrom exploit was the 3GS.
The whole problem is that no one tries to use iMessage, the texts just get automatically converted and sent over that system when you are both on apple devices.
I was a huge apple fan when they were the underdog, but they are getting a little too big now. iO$ is still the best target operating system for developers, I just wish I didn't like apple's products so much.
Is the free software alternative you talk about hypothetical or do you have any concrete piece of software to refer to, preferably one that would interoperate with OP's peer group of 99% iOS users?
