9 ms·

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

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.

theturtletalks 3y ago
What’s stopping an open source beeper alternative where users host their own notification server? The rest is client-side anyways.
- solardev 3y ago
  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.
  - theturtletalks 3y ago
    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.
    - derefr 3y ago
      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…)
      - jkarneges 3y ago
        > 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)
        derefr 3y ago
        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.
skeaker 3y ago
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.
- kbenson 3y ago
  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.
  - freedomben 3y ago
    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.
    - skeaker 3y ago
      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.
    - kbenson 3y ago
      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.
badwolf 3y ago
Good news, once Apple implements RCS next year, no more postage-stamp sized MMS! Halleloo!
- websap 3y ago
  Really hope Apple makes a banger implementation of this. Not whatever Google and Samsung have been upto now.
ants_everywhere 3y ago
> SMS Can you change the SMS app on Apple devices now?
- irjustin 3y ago
  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.
  - ants_everywhere 3y ago
    > 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/guide-antitrust-laws/single-firm-conduct/monopolization-defined https://www.ftc.gov/advice-guidance/competition-guidance/gui...
camkego 3y ago
"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.
- 2muchcoffeeman 3y ago
  Android has 70% market share.
- GeekyBear 3y ago
  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 https://www.youtube.com/watch?v=MZ23ExDJSec
daedalus_j 3y ago
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.

theturtletalks 3y ago

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

solardev 3y ago
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.
- theturtletalks 3y ago
  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.
  - derefr 3y ago
    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…)
    - jkarneges 3y ago
      > 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)
      - derefr 3y ago
        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.

skeaker 3y ago

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.

kbenson 3y ago
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.
- freedomben 3y ago
  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.
  - skeaker 3y ago
    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.
  - kbenson 3y ago
    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.

badwolf 3y ago

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

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

ants_everywhere 3y ago

> SMS Can you change the SMS app on Apple devices now?

irjustin 3y ago
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.
- ants_everywhere 3y ago
  > 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/guide-antitrust-laws/single-firm-conduct/monopolization-defined https://www.ftc.gov/advice-guidance/competition-guidance/gui...

camkego 3y ago

"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.

2muchcoffeeman 3y ago
Android has 70% market share.
GeekyBear 3y ago
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 https://www.youtube.com/watch?v=MZ23ExDJSec

daedalus_j 3y ago

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.