Live data from Hacker News

Beeper Mini is back

blog.beeper.com

61–70 of 1001 posts

Re: Beeper Mini is back

#61

These Beeper folk sound a bit entitled. As was repeatedly mentioned in the other thread [1], building production applications on top of an undocumented and unsupported (in terms of backwards compatability, etc) API is a nightmare that should be avoided. Apple has every right to change their API, if they do Beeper will go down, and Beeper will blame Apple. I understand Apple's incentives to not want to be in this situ…

If the only thing Beeper does is continue to make Apple look anti-competitive, they've succeeded as far as I'm concerned.

I'm deep into the Apple ecosystem and don't see myself getting out anytime soon. But I think their stance on iMessage sucks, even while understanding the strategic reasons they're doing it.

I don't see this as "leeching off an undocumented API" as much as demonstrating that iMessage is already in a state that allows 3rd parties to interact with it, documented or not. Every time Beeper starts working again, it shines a light on the fact that iMessage was never so locked down to begin with. It also puts pressure on Apple to answer the growing # of their own customers who are frustrated by the limits. These are good things, IMO.

Apple may have every right, but that doesn't make their stance good for the ecosystem or good for consumers. This is pretty clearly about forcing people to switch ecosystems and not about security. If security was the only issue, Apple could easily provide supported iMessage APIs that make it clear that the other user is not a verified Apple user, while still allowing interoperability.

Re: Beeper Mini is back

#62

These Beeper folk sound a bit entitled. As was repeatedly mentioned in the other thread [1], building production applications on top of an undocumented and unsupported (in terms of backwards compatability, etc) API is a nightmare that should be avoided. Apple has every right to change their API, if they do Beeper will go down, and Beeper will blame Apple. I understand Apple's incentives to not want to be in this situ…

Devil’s advocate: does Beeper opens up iMessage to spam bots?

Re: Beeper Mini is back

#63
post #10

Earlier quoted context omitted.

They're either going to keep getting their access cut, or sued into bankruptcy. You can't really piggyback off another companies service in violation of their TOS without things working out poorly for you IMO.

Yeah, not the point. The point is to prove that it's possible and relatively simple, and the only reason Apple operates this way is to lock people into the ecosystem.

Running the iMessage service for a billion iPhone users can't be cheap. Opening up the API and running it for the entire rest of the world for free is a non-starter.

No company on earth is that generous, let alone Apple.

Re: Beeper Mini is back

#64
post #2

I have a feeling they're not going to stop being a thorn in Apple's side for quite a while...

They're either going to keep getting their access cut, or sued into bankruptcy. You can't really piggyback off another companies service in violation of their TOS without things working out poorly for you IMO.

[deleted]

Re: Beeper Mini is back

#65

Crazy that Apple gets to ship a proprietary messaging app as the default

Apple is lucky that iMessage usage in EU is irrelevant.

Otherwise this kind of thing would have been regulated already.

See what's happening to Safari on iOS. Took a long time if you ask me.

Re: Beeper Mini is back

#66
post #36

These Beeper folk sound a bit entitled. As was repeatedly mentioned in the other thread [1], building production applications on top of an undocumented and unsupported (in terms of backwards compatability, etc) API is a nightmare that should be avoided. Apple has every right to change their API, if they do Beeper will go down, and Beeper will blame Apple. I understand Apple's incentives to not want to be in this situ…

I think they are rightly calling out that iMessage as part of Apple's moat building is both bad for their customers and people their customers interact with. And while I agree with you, and I won't be using the service, I think from their POV it is the correct messaging.

I think it's valid feedback from Beeper, but to insinuate that this gives them to right to force Apple to run their reverse-engineered access is where things go a bit too far for me. Apple's customers are not Beeper's customers. They have completely different incentives.

I guess the approach is to try and force Apple's hand or push some legislation for interoperability, but Apple is working on RCS so it's not like they've been completely ignoring criticism...

Re: Beeper Mini is back

#67
post #36

These Beeper folk sound a bit entitled. As was repeatedly mentioned in the other thread [1], building production applications on top of an undocumented and unsupported (in terms of backwards compatability, etc) API is a nightmare that should be avoided. Apple has every right to change their API, if they do Beeper will go down, and Beeper will blame Apple. I understand Apple's incentives to not want to be in this situ…

I think they are rightly calling out that iMessage as part of Apple's moat building is both bad for their customers and people their customers interact with. And while I agree with you, and I won't be using the service, I think from their POV it is the correct messaging.

Apple is at a scale in smartphone dominance that they're anticompetitive. There are only two vendors. They control everything about one of the most essential functional pieces of modern society.

A smartphone is essential. Apple and Google tax 30%, control when and how software can be deployed, control browser tech (Apple), prevent web downloads of executable software (Apple) or scare and confuse you about it (Google). They control the payment rails and increasingly enforce using their identity and customer management, so they can sink more claws into business and innovation. They're partnering with governments to be authoritative identify providers. They're usurping payment rails to become the entire payment ecosystem of the future.

The devices are user unfriendly. Can't repair them, can't use third party components, can't replace the battery. Unofficial pieces break core features due to unnecessary cryptographic locks. Updates obsolete old hardware.

Nevermind the petty bullshit about green and blue bubbles giving children (and even adults) fear about their image and reputation. Being bullied for not buying the latest and greatest.

This is scary shit and we're letting them do this.

Nevermind all the fluff of them owning movie studios and music and the arts to keep eyeballs locked.

Car companies wish they had it this good. They'd love to charge you for third party accessories, or to charge McDonalds a fee every time they drive you there. That's essentially the deal Apple and Google are getting.

This is all at once worse than Standard Oil, and comes with heavy Orwellian vibes.

We need more than two vendors, and we need different companies to own different parts of the stack. As it stands, these two companies own everyone and everything these people touch.

Re: Beeper Mini is back

#68
post #49

These Beeper folk sound a bit entitled. As was repeatedly mentioned in the other thread [1], building production applications on top of an undocumented and unsupported (in terms of backwards compatability, etc) API is a nightmare that should be avoided. Apple has every right to change their API, if they do Beeper will go down, and Beeper will blame Apple. I understand Apple's incentives to not want to be in this situ…

You think an E2E encryption messenger is best served by a proprietary, single vendor implementation, with the added bonus of being able to subvert the client at any moment for individual devices? There are some very weird takes around security on this to somehow twist it into an "Apple good" scenario. No, like literally every other time in history , closed & controlled does not make it more secure.

Isn't Whatsapp a proprietary, single vendor implementation? Isn't Signal a single vendor implementation? I'm confused on your point.

Re: Beeper Mini is back

#69
post #49

These Beeper folk sound a bit entitled. As was repeatedly mentioned in the other thread [1], building production applications on top of an undocumented and unsupported (in terms of backwards compatability, etc) API is a nightmare that should be avoided. Apple has every right to change their API, if they do Beeper will go down, and Beeper will blame Apple. I understand Apple's incentives to not want to be in this situ…

You think an E2E encryption messenger is best served by a proprietary, single vendor implementation, with the added bonus of being able to subvert the client at any moment for individual devices? There are some very weird takes around security on this to somehow twist it into an "Apple good" scenario. No, like literally every other time in history , closed & controlled does not make it more secure.

Like Signal?

To my knowledge, you can't make a 3rd party Signal client and connect it to the official Signal instances.

Re: Beeper Mini is back

#70

These Beeper folk sound a bit entitled. As was repeatedly mentioned in the other thread [1], building production applications on top of an undocumented and unsupported (in terms of backwards compatability, etc) API is a nightmare that should be avoided. Apple has every right to change their API, if they do Beeper will go down, and Beeper will blame Apple. I understand Apple's incentives to not want to be in this situ…

Your Apple ID login is not routed through a third party when you use Beeper Mini. You don't have to input your Apple ID at all.

Edit: Should have read this new post more closely. They are now requiring an Apple ID, when they weren't before.

Post reply on HN