Because Ma Bell was a regulated monopoly, and iMessage is not a monopoly. People routinely use WhatsApp, Signal, Telegram, SMS, FB Messenger, etc.

Don't get me wrong, I love that these guys are poking the bear. I wish Apple would do something to let me send high-quality photos and videos to my Android-owning friends via "text". But I don't think the government has a place to force that issue. Plenty of alternatives exist.

"Jury Rules Google App Store Operates as Monopoly" is in the headlines this week. So it seems maybe there is some risk to Apple with regards to iMessage.

Google was found guilty of antitrust violations, not of having a monopoly.

Having a monopoly is not illegal.

Here's an explanation of the verdict from a lawyer familiar with tech and antitrust.

> EPIC WIN | Why Google Lost and What it Means For Apple

https://www.youtube.com/watch?v=MZ23ExDJSec

Android has 70% market share.

Why not let the government intervene here? Typically my reason for wanting government to not do stuff is because it could affect me, but none of us will never be a trillionaire corporate entity, so anything done to Apple wouldn't apply to us as a precedent. If anything, you could argue that part of the purpose of the government is to stand up to these giant businesses that the average person can do nothing to.

While I'm also in favor of Apple doing something, anything really, that's better than the frustrating status quo, I could see how blunt/incompetent regulation might weaken encryption.

I've been wondering if we can already see the foreshadows of Apple's next move, actually: CKV is already only possible between modern (iOS 17.2 or macOS 14.2 and above only) devices, and their RCS implementation will presumably not be end-to-end encrypted.

I could see them opening up "legacy iMessage" (i.e. non-CKV, non-ephermerally-encrypted) and integrating RCS, but assigning new color to "modern iMessage" exclusively. That would credibly count as opening up their service, while still preserving a distinguishing feature for Apple devices, and even nudging people to upgrade some old devices.

Because usually precedents are not so narrow as to apply towards trillion dollar companies only, and even if they are they can be expanded upon. If you would be against a trillion dollar company forcing a small competitor to open up, you should rightly be worried about allowing the reverse, because the principles by which they justify it are unlikely to discern based on company size.

I (mostly) do favor government intervention with Apple, but you make a good point. Originally the income tax was only to apply to the uber mega rich. It didn't take long for it to apply to all the middle class too.

Yes, that's a fair point, but it hinges on the law being weak and poorly worded. Obviously I would not be happy with that either. But loopholes like that are a risk with any action that the market or the government would take, and ideally I would like the government to make a strong, well-worded law that accomplishes only the original intent, which can and does happen frequently as well.

The trick is finding justifiable, reasonable reasons that don't cause havoc with our economic system, which IMO necessitates they they not target an arbitrary employee size or specific market percentage, or revenue. What is "large" is very relative, and not just by individual opinion, but temporally. What was a large company just 70 years years ago is nothing compared to those of today.

As much as I would like to see Apple, Google, Amazon, Microsoft and the like not have so much power (socially, economically, most likely at the government level as well), I think the only way we'll actually make any progress towards the problems that allow large companies like that and allow their negative consequences is to attack some of the specific aspects of our current system they abuse to their benefit, and not them specifically.

For example, very strict privacy laws and control over tracking to curtail the biggest problems of the data companies, laws about control over your own devices and what you do on them (software) and with them (repair) for the hardware companies, etc. Otherwise we'll just see some other company take up the same practice and have all the same problems.

Why let them intervene? The government isn't there to cure all ills, nor should we want it to be. This seems like something the market can handle. Messenging systems have come and gone (ICQ, AIM, MSN, Yahoo Messenger, Blackberry, etc., etc., etc.). They've been locked to hardware, semi-open, and completely open. There will be dozens more, all with their own benefits and drawbacks. Fortunately, not one is required for any part of life.

> Why let them intervene?

Because it would be the most sure-fire way to be certain that it actually gets done, whereas "the market" is less certain and prone to manipulation tactics such as lock-in. Returning to my original question that you kind of dodged, why not let them intervene?

Good news, once Apple implements RCS next year, no more postage-stamp sized MMS! Halleloo!

Really hope Apple makes a banger implementation of this. Not whatever Google and Samsung have been upto now.

What’s stopping an open source beeper alternative where users host their own notification server? The rest is client-side anyways.

Network effect? The whole value of it is that it lets you use existing networks (iMessage and SMS). Otherwise people could just switch to WhatsApp or any of twenty Google messaging services.

No I mean a beeper alternative that uses the iMessage backend. The tricky part with beeper is that they have their own notification server that gets the notifications from Apple and turns them into what android understands. That should be self-hosted by each person because it would contain the FairPlay key.

It’s a trivial cost that people don’t want to pay. Sadly it can’t be run as some kind of ala-carte computation that can scale-to-zero like a Lambda function can, because it needs to be an active connection-oriented daemon that keeps per-connection state — i.e. something that always maintains at least one real OS thread, holding open real OS sockets, on the same machine (so that those sockets don’t break at the TCP level.) In other words, for an individual to deploy their own push daemon, it would necessarily need to live on a $5/mo VPS or something. And people don’t value iMessage at $5/mo.

(…which naturally leads to the question: why is there no Lambda-like serverless compute substrate that allows your function to speak a connection-oriented protocol, by externalizing the connection-hold-open and per-connection book-keeping state into the routing layer, such that your own function in the system could scale-to-zero? Exactly like Pusher did for websockets 15 years ago, but routing to a vertically-integrated serverless compute layer rather than a “passive” PHP/CGI-ish REST backend. Seems like an obvious extension for Cloudflare Workers…)

> why is there no Lambda-like serverless compute substrate that allows your function to speak a connection-oriented protocol, by externalizing the connection-hold-open and per-connection book-keeping state into the routing layer, such that your own function in the system could scale-to-zero?

Fastly Fanout + Compute?

(disclosure: Fanout tech lead)

Not generalized, AFAICT; from reading the docs, Fanout just does websockets, no?

I'm talking about a routing layer that could allow a serverless function to be the backend for an arbitrary stateful TCP protocol, e.g. IRC, SMTP, FTP, PGSQL, etc; where the service doesn't need to add support for a new L7 protocol for functions to use it; instead, the support for the L7 protocol is part of the function, the same way it's part of a regular network daemon.

I would imagine that this would work like the following:

- the logic for the L7 protocol's connection state-transitions lives within the stateless function;

- each call to the stateless function is handed the pre-transition L7 state, and returns the new post-transition L7 state, with the routing layer persisting this state between calls. (Compare/contrast: Erlang gen_server state management, between the gen_server module [routing layer] and the user-supplied delegate module [compute layer].) Any arbitrary compute node can then handle each "step" of the computation... but only one compute "worker" at a time will ever be tasked with handling messages for a given connection, because each call requires an input L7 state, which depends on the output L7 state of the previous compute-step;

- the function declares in its metadata what L4 protocols it accepts (TCP/UDP, maybe SCTP or DTLS, or TCP+TLS, etc); the routing layer then manages flows for these as portable persisted state-machine-state resources on virtual IPs owned collectively by the routing layer mesh — similar to how a distributed wireless AP or eNodeB manages established flows across its listeners;

- likely, the L4 state lives in the same persisted (distributed KV?) store as the L7 state, but just isn't passed back to the serverless function — except for maybe SNI info in the case of TLS. (This would make sense to me because you're never going to update the L7 state without also updating the L4 state. I can imagine a connection-listener state machine that touches the "L4 part" of a backing data-structure in response to most L4 packets, but then, when it's built up enough of a buffer to have a complete L4 message†, it would pass the message to the L7 and get an L7 update in response, and then commit a new L4+L7 state together.)

- And yes, the †ed part above means that another required part of the serverless function's metadata, would be a definition in some language of a lexer/parser for recognizing+extracting toplevel L7 messages from the carrier stream, such that the routing layer would then use this lexer/parser to know when it has one or more lexically-complete messages in its buffer to be pushed down atomically to the compute layer. (I say "lexer/parser" because mostly this code wouldn't have to parse messages — the L7 is still receiving just a stream of bytes it's expected to parse itself; but it's required to be "just a stream of bytes" sliced to consist of exactly one L7 message per call. So for most protocols, this would be cheap: most stateful protocols are either "newline is always toplevel break" or they're binary length-prefixed, and these can both be delimited by a dumb lexer, or even a fixed-buffer DSP-alike. Sadly, though, some stateful protocols require full parsing to know where each message ends. So the routing layer would need to support both — probably with a lot of "function compilation time" grunt-work put into recognizing when the routing layer can apply less than a full Turing-complete parser to the task.) Probably for most protocols this could look like an abstract-DSL version of something with capabilities equivalent to a Wireshark dissector definition or eBPF bytecode; and that in turn could be abstracted over with something like a "buildpack" / "cloud-init" sort of strategy, where instead of supplying the code yourself, you supply the URL of a repo that contains the code.

Thanks for the thoughtful reply. What you describe sounds awesome, and in fact some of these concepts are present in our stack but not fleshed out to this level, so maybe we could get there someday. The challenge is making it practical.

Currently, Fanout supports HTTP in addition to WebSockets. We consider the system to be generalized, in the sense that the user can build whatever they want on top of the available primitives, and we can always add more primitives. Most people are implementing "web" protocols (REST, SSE, GraphQL, etc), so what's available today gets us pretty far. You're right of course that we don't support arbitrary TCP protocols.

I suppose the reason we don't support bare TCP is Fanout is optimized for implementing pub/sub-style interfaces with minimal compute. In that context, it is preferable to work with coarse-grained input in order to avoid per-session processing. However, with Fastly Compute now in arms reach, I think we could embrace per-session processing, in which case implementing arbitrary TCP protocols could become practical.

Your idea of supplying custom L7 parsers to the routing layer is clever, and is not too far off from some things already on our mind. For example, our routing layer supports inspecting requests using custom rules supplied by the compute layer, though this is not yet exposed to Fastly users. Relatedly, the routing layer has an internal component that parses TCP streams into messages (by known protocol) and ships them over an IPC without caring about their content. So it's not too much of a jump to imagine how we could get to user-supplied L7 parsing.

> SMS

Can you change the SMS app on Apple devices now?

This is conflating problems.

This thread is about asking the government to step in to allow 3rd party devices into iMessage, which is decidedly outside of SMS, but gov won't step in because iMessage isn't a monopoly on messaging nor SMS. It's a monopoly on... it's own protocol/service?

Android users always get a message an iPhone user sends so to claim gov intervention monopoly on the basis that the end user can't change the SMS app isn't an argument.

> iMessage isn't a monopoly on messaging nor SMS

People tend to misinterpret what it means to be a monopoly for antitrust law. The obvious example here is United States v. Microsoft Corp., where the inability to remove Internet Explorer was at issue. Being unable to set an alternative messaging app with equivalent functionality (such as Signal) on a mobile phone is at least as cumbersome to the user as being unable to uninstall Internet Explorer, despite the ability to install competing browsers. The iMessage case is arguably worse because the competing browsers had the same features as IE. Apple uses its control of the handset to disable other messengers from supporting SMS on iOS.

Also relevant in that case is that Microsoft was argued to be a monopoly not over all computers or even all desktop computers, but over intel-based personal computers. This illustrates that the scope of the market in these cases is often smaller than one might initially think.

The FTC has a page here that goes into it [0].

> Then courts ask if that leading position was gained or maintained through improper conduct—that is, something other than merely having a better product, superior management or historic accident....Courts do not require a literal monopoly before applying rules for single firm conduct; that term is used as shorthand for a firm with significant and durable market power — that is, the long term ability to raise price or exclude competitors.

In this case, forcing users to use iMessage for SMS decreases the likelihood that users will install an alternative messenger with a smaller feature set due to Apple's control over the OS.

That reduced likelihood compounds quickly because the popularity of a messenger tends to scale with the square of the install base.

[0] https://www.ftc.gov/advice-guidance/competition-guidance/gui...

Thanks I appreciate the deeper explanation.

For discussion, using MSFT vs US as the central point, it seems as if US was arguing that Windows and IE were "one and the same" or at least inseparable as concepts while the US gov said no way.

Applying that central argument to this situation doesn't feel the same in that, if US gov tried to apply the same argument it would lose in this case.

When I think "phone device", I think phone calls and SMS are inseparable ideas to the device itself. That they are functions that belong to the phone. Probably stems from my days of owning a Nokia or Razor.

But maybe that is an out dated concept and my thinking needs to change because any program should be able to control the phone's SMS and calling function via API.

I'm unsure is all I can really say.

You can choose to use sms only, and not use iMessage messages.

This. This is what Apple should ACTUALLY get punished for. I don't care that they intentionally lock down their service I wouldn't use it anyway as it's not as secure Signal.

What I DO care about in that they intentionally degrade the experience for communicating outside their garden.

Maybe it'll get better with them finally supporting RCS, but I doubt it. If only they were compelled to let users install an SMS handler app of their choice, then this whole "green bubble" thing would instead be a "geez, why is my iPhone so shitty at handling SMS" thing instead.

It's not the equivalent.

If the third party phones allowed users access to Ma Bell's network, switching systems, etc, without paying Ma Bell - then it might be equivalent.

I'm pretty sure that would be considered theft of communication services.

I feel that's not right either. Apple did not physically build the phone network and nobody is piggybacking on their network, Apple isn't hosting anyone's photos or videos afaict and the user pays for bandwidth, they maybe pay for notification relay to their own users.

It's more like phone manufacturer X that accesses Ma Bell's network creates phone with slightly better call quality that only works with other X phones and is worse with anyone else's phones. And they start doing that once they have >50% market share.

Apple did build out the iMessage service and pays the bills for the servers it runs on.

Aaron Swartz was hounded to death by the Feds for unauthorized access to a website and charged with a violation of the Computer Fraud and Abuse Act

He wasn't even trying to turn a profit.

Traffic goes to Apple’s servers.

Servers handle routing and storing. iMessage will deliver and store the message to server, and then to receiver when it is online.

It is major cost when there are millions of users on, top of notifications.

User pays for ISP, only up to the closest link.

What type of infrastructure and operations do you think is necessary to handle 8.4B messages per day. So far, the cost of those systems and teams has come from hardware sales. The benefit is that it is effectively a paid for service and doesn't need external support from advertisers or by selling user data.

It really depends on what stack you pick and what kind of engineers you have. What's App famously used Erlang (an excellent choice for this) and was able to scale to astronomical levels with a fairly small engineering team and hundreds of instances.

A couple hundred servers, and like 5 engineers.

Minimally that’s a few million dollars per year for KTLO. At least a few million more for ongoing development. Why should it be free for everyone?

Ma Bell had a monopoly.

This is one messaging app on one brand of phone. Nothing stops you from using another phone, or multiple or other messaging apps. And messaging apps aren’t restricted by a “default” in quite the same way a web browser is. I have friends on WhatsApp and Signal and Instagram and I message them all without any appreciable difference in effort.

You can run that argument the other way. It's desirable for there to be only one system of phone lines installed everywhere, where anyone with a telephone number can call anyone else. It would be desirable for there to be only one e2e encrypted "double-ratchet" messaging protocol, for the same reasons.

In the case of Bell, the universal lines already existed, the problem was that Bell owned them all and wouldn't let anyone else use them. That was a "monopoly" so there was an argument for breaking it up so that everyone could use the lines.

In the case of iMessage (and others), the creators are deliberately building out many different incompatible "lines", and not letting anyone else use those lines. And now people are coming along and saying because it's not a "monopoly", we can't do anything about that. But the real goal was the same in both cases - making universal communication possible. That's what we're all frustrated about here, and the fact that there are dozens of apps trying to wall off competitors is part of the cause of that. Apple is a target because iMessage is the largest such "private line" in the United States.

> It's desirable for there to be only one system

What gets a bit lost in the conversation for iMessage is that the protocol/infra and implementation get merged into one. This is approached in many countries for telcos by splitting the companies providing the lines from the companies providing service on top of them. It's not perfect, but it's better than previous approaches.

As long as iMessage doesn't support federation, Apple has a monopoly on it too. If not, then Ma Bell wouldn't have had a monopoly either, since you could say mailing letters was a competitor to telephones.

And here you are, posting on a site with a monopoly on HN comments.

That's nonsensical. Reddit has a monopoly on Reddit - of course it does.

Any service online is under no obligation to allow for widespread interpoperation - that would be madness.

> Any service online is under no obligation to allow for widespread interpoperation - that would be madness.

Lol, "madness". The Digital Services Act in the EU would like a word.

Although the final determination is not yet locked in, the word is that Bing and iMessage have been found to not be popular enough in the EU to fall under the DMA.

https://www.bloomberg.com/news/articles/2023-12-06/apple-ime...

You can see full list of current decisions here without paywall:

https://digital-markets-act-cases.ec.europa.eu/gatekeepers

You are confusing with Digital Markets Act.

https://digital-markets-act.ec.europa.eu/about-dma_en

It's madness for monopolistic communications providers to refuse interoperability.

iMessage is far from monopolistic.

Messages on iPhone is interoperable with any other mobile device - it supports SMS!

> it supports SMS!

and isn't RCS support coming too?

Right. This is much more similar to MS and Internet Explorer back in 98.

Interestingly enough, one of the outcomes of that case was IE for the Mac.

It required no ongoing infrastructure for people to use IE either on Windows or on Mac. iMessage requires servers, bandwidth, and operators.

Yeah, they're definitely not identical. But from an antitrust perspective I think the MS case is at least much more similar.

>. Nothing stops you from using another phone,

Do you realise phones cost money and not everyone can afford an iPhone?

I guess the EU will be closely watching with Digital Services Act

Unfortunately, the EU isn't going to save us with this one. iMessage usage is minimal in the EU because so many people use alternate messaging services, and the EU already ruled that iMessage won't be forced open because it isn't widely used by business users.

In the US, iMessage market share is much higher because back in the aughts we didn't have the sky high SMS rates which forced so many users to other messaging services in other countries.

I would suggest that as often as not, when the EU intervenes in technological affairs the result isn’t that things get massively better but rather that people are forced to deal with corporations finding ways to maliciously comply with the letter of the law.

Exactly: here outside the US, absolutely no one uses SMS, so no one cares about this issue at all. It's like arguing over the rights to videotape standards. So to me it's somewhat amusing reading these arguments here.

Why, when use of iMessage is a rounding error across the European Union, will the EU rule that Apple are a messaging Gatekeeper? The noises coming from the investagtiong body seem to indicate that they will not treat iMessage as such.

Beeper is commercial app, and because of that it classifies as ”unfair”, unpermitted use of Apple’s private services.

They are making supporting argument for Apple, unfortunately, if any regulation happens.

Why are y’all so intent on using iMessage? I (honestly) don’t understand the serious passion behind forcing Apple to open it to everyone.

SMS still gets through, and other apps still work. It seems weird to focus so much on this and not on just using something that fits your use case, but maybe I’m missing something.

It's because SMS is unencrypted, and this is an effort to have secure communication between iOS users and Android users (since iMessage is Apple-device-only). There's also a status factor, where Android users are lowly "green bubbles" in iMessage, which signals decreased security and questionable support for the interactions available to iMessage users.

Of course everyone can switch to Signal and this is a moot point, but millions of Apple users use iMessage and aren't likely to switch.

> Of course everyone can switch to Signal and this is a moot point, but millions of Apple users use iMessage and aren't likely to switch.

Doesn’t this mean that most people simply don’t care?

On the iOS side people don't care, but apparently on the Android side they do?

How many people really care about encrypted text messages? Most of the time, I’m sending my girlfriend pictures of our dogs. If I cared about encryption, we’d download something else (or use gchat or whatever). This just doesn’t seem like it should be that big a deal.

Yeah it seems like it's more about "blue bubble" status than it is about encryption.

This has been discussed ad nauseam. In the US, not being a "blue bubble" can have a very high social cost and get you excluded from groups and communication opportunities. People just want to be able to communicate without ridiculous walled garden vendors throwing stupid road blocks in their way and making things artificially harder to get you to "buy your mom an iphone."

The fact that some people are snobs doesn’t justify the government dictating software specifications to Apple.

It's not just snobbery. There are real and serious usability issues. When doing group communication between an iPhone and a group member who is in Android user. The entire group chat gets downgraded to SMS, which means a lot of messages don't get through the way they were intended, and images and videos are so downgraded as to be unusable. The people that I know personally who are affected by this, it has nothing to do with snobbery and everything to do with pragmatism. People on iPhone will only use iMessage in the United States. It's stupid, it's absurd, it's self-inflicted, but ultimately it is what it is and all the advocacy of moving to something else is not moving the needle.

If Americans are this dumb, I don't see why they need any laws to protect them. Why would I want to be part of any groups that won't have me because I don't use an iPhone?

Thankfully, here outside America, this isn't an issue: absolutely no one uses SMS or cares about this stuff.

> If Americans are this dumb, I don't see why they need any laws to protect them.

They aren't. The bubble color thing is an exaggerated claim and a lot of whining from a bunch of clowns. No one actually cares in the US except for a bunch of children (who are always prone to following trends for the sake of following the trend) and a handful of immature adults. The rest of the country doesn't know or care

That's a very ignorant thing to say. Try to force yourself to live with images and video of quality to SMS so you can actually understand the problem, and let's see how long you think it's just immaturity.

We can disagree about solutions, but strawmanning stuff is dumb, and then dismissing the problem that you strawmanned is even more dumb

What's ignorant about it? MMS sucks, I didn't say otherwise. Android <-> Android MMS also sucks. That is not an iPhone <-> Android specific issue. MMS was an adequate solution in the feature phone days when the phones and displays were mediocre at best. It's been a terrible solution since mobile phones became cameras with a phone.

The strawmanning is done by the people claiming iPhone users are, as a whole, excluding Android users from their communications over it. That's what I'm rebutting, not that MMS sucks. Only children and immature adults do that. The vast majority of people don't care. They either use MMS and accept it sucks or switch to another service, they don't exclude people over it.

That’s a ridiculous reason to demand an open protocol from Apple. I get that it sucks when you’re in high school and kids are massive jerks about social standing, but this can’t be a serious use case post college, right?

Anecdotes about mean girls on Tinder dumping Android users don’t really seem compelling, either.

It is surprisingly a serious use case post college. In my personal life, if someone is going to be so stupid and immature as to not want to communicate with me because I'm an Android user, then good riddance. I don't need people like that in my life.

However, there are a lot of people who are impacted, and it's not always the case of the mean girl on tinder dumping an Android user. I know people who have group chats with family and friends, that will be left out because the iPhone is programmed to downgrade the entire group's chat if a single member is an Android user. This makes it so that messages don't work all the way, quality on images and video is garbage, and other legitimate usability concerns. Are super snooty, it's that it truly is very difficult to communicate from an iPhone to an Android phone.

Because Apple has enough cash to pay off enough congressmen.

> ... nobody is piggybacking on their network.

I would suggest that is exactly what Beeper is doing. Not the end users ISP / WAN connection obviously, but certainly Apple's iMessage infrastructure (servers, switches, bandwidth, etc).

iMessage is not a simple P2P platform.