How does this work? Do you have an agreement with Apple to connect to their iMessage service? If you do then kudos thats a real differentiator.
However if you're hosting your own mac mini farm and running bluebubbles or other such things that are not approved by Apple what is your plan to handle the case where you're sending enough traffic through Apple's services that they disable / ban / block you?
If its the former then awesome but if its the latter then Im not sure I'd want to depend on your service knowing that apple could ban you at any time.
Apple wouldn't ban us since we're not doing anything that would qualify as spam or abuse. Even if that hypothetical event does happen, we have SMS/RCS fallback systems in place so no conversations get stopped or lost
As someone who has been in the messaging industry for more than a decade, it sounds naive to think that the litmus test for whether Apple will ban you is whether your traffic qualifies as spam. There is a long history of people trying to get around A2P spam filters / fees / traffic limits / onboarding / KYB requirements by running business messaging on P2P pipes, like you are doing. Some of it has been successful (see Twilio in the early days) but the industry has gotten a lot more sophisticated around this stuff and is not going to be receptive to your approach, which to me resembles the SIM farms that are a scourge when it comes to consumer fraud and abuse.
Much of what you mention in your post seemed spammy; messaging regarding cart abandonment, etc. I aggressively label messages like that as spam, and I suspect others do too. I also suspect after blasting out messages like that, your accounts will get burned.
Could you elaborate? What does that mean in practice?
So far what I’ve seen from your service seems to be yet another attempt at blurring the distinction between bots and human interactions, which is generally used for spammy content
We're working to bridge the interaction between humans and bots so that automated conversations feel more natural and comfortable for the end user. In circumstances where the user can't reach an actual human (e.g. off hours support), they're often faced with bots over SMS/RCS that feel non-conversational and therefore can't support them in the right way due to interface. We're working on building agents that can more comfortably interact with users during those situations.
The ideas like this one are the rarest of the startup ideas you wish they don't become too successful as they are the target for exploitation by bad actors with ad dollars quickly.
Apple doesn't inherently prohibit programmatic messaging. In fact, they actually developed Applescript for people to do that. What they are against is spam and abuse. Therefore, as long as we stay compliant and prevent spam, Apple is not necessarily against this.
How are your financial incentives aligned against sending spam? From this side, your words seem hollow and the typical viability of these businesses relies on sending spam.
They developed AppleScript for people to do this individually, at limited scale.
Push notifications, attached to an application or website, and controllable by a user on that basis, are the solution for corporate messaging at scale.
This will get you banned. It’s not a question of if, but when. Users will hit the report spam button. Apple will shut you down.
People don't report our phone lines to be spam because the use cases that we focus on are either mostly inbound (e.g. customer service, the user is the one who texts first) or warm opt-in outbound (e.g. form-fill text back or follow ups). Businesses want a better medium to communicate with their users and users want something more conversational and native to their messaging behaviors.
I genuinely can’t tell if this is naivety or willful ignorance, but at the end of the day, it doesn’t matter.
This is in direct violation of the terms of service, and Apple invests a lot of money in keeping iMessage clean of this kind of misuse.
They control the servers, the client, certificate provisioning, hardware identification, and user identification. They can trivially trace a registered account to the point of sale and the card and PII used to buy the hardware on which the account was registered.
You will fly under the radar for just as long as it takes to annoy enough of their customers that Apple brings down a massive ban hammer.
We're not encouraging spam with this. We're mainly focused on existing conversational use cases that's currently done over SMS/RCS. They can be more human and expressive when done over iMessage.
what you encourage and what actually happens are two different things, though. gmail does not actively encourage spam, yet most spam emails i receive are from gmail addresses.
you have to actively fight against malicious uses, like spam. "not encouraging" is nowhere near enough.
what systems/processes/safeguards do you have in place to prevent abuse?
I agree. We're not completely self-serve right now, so we get to talk with each potential customer and learn about their use case before onboarding them onto the platform. This way, we can prevent use cases that involve spam or abuse.
"right now", which implies that you plan to move to self-serve. and obviously manually checking in on each and every customer is not sustainable if you scale.
do you do periodic checkups now? hoping nobody lies during onboarding is risky, in an already-risky endeavor. have you thought about anti-abuse systems for when you go self-serve?
For iPhone only users, so right off the bat your product is targeting 50% ish of a companies customer base. And the non iMessage people get a worse experience?
Isn't this a direct violation of Apple's terms of service? You say you aren't spammy but at a certain point you will get banned. I'm not sure how YC funded this based on the platform risk alone but I guess these days they're throwing anything and everything at the wall.
We're helping to support conversational customer support agents that can help users better during off-hours and scheduling assistants that can interact with and understand user requests better than current models over SMS/RCS. This is definitely not just spam but instead the future of conversational 2-way messaging.
I will say I am the exact opposite of your market, I want absolutely nothing like this. In fact I'd prefer iMessage to allow ZERO programmatic interfacing.
While Blooio and Sendblue are more focused on B2C agents and sales, we're more focused on 2-way conversational business use cases such as customer service that require scale and stability.
A few ideas for you guys:
1. Apple already supports iMessage for Business which is intended to cover the use cases you are targeting. But the set up process is ridiculous (for example: https://help.webexconnect.io/docs/wxcc-apple-messages-for-bu...). It would be amazing to have "Vercel/Resend for iMessage for Business"
2. If you go the send blue route, please support iMessage app payloads. Send blue doesn't support that
Thanks for the suggestion! Yes, the setup process is extremely long and requires a lot of documents from the side of the business haha. It's definitely one of our goals to create the Vercel for iMessage for Business. Also, for the iMessage app payloads, that's an awesome suggestion! We can work on building that.
how is it possible to build this whole thing and not know there is a very rich first party api that does the same thing and more in iMessage
https://www.apple.com/ios/business-chat/
iMessage for business has a very long and restrictive registration process, gray bubbles instead of blue bubbles, and is inbound only. We're democratizing iMessage for businesses that have good intentions on helping their customers more but can't afford to go through the long approval process.
we don't think AI should by any means to pretend to be human, and we are not trying to hide that an agent is involved.
What we mean is that conversation should feel natural and low-friction for the person receiving it. These interactions: blue bubble interface, typing indicators, and reactions will make it less like an automated SMS message and more like a normal messaging flow.
We are trying to make agentic communication clear, useful, and native to channels people already use!
1. Since we're not fully self-serve right now, we can choose to only partner with businesses with use cases that are opt-in and non-spam.
2. If we find that one of our customers is using this for spam, we'll reach out to them asap and determine next steps
3. Not necessarily. We support both inbound (user texts the phone line first) and opt-in outbound (we text the user first) use cases
And what would be the next steps? Would you block them from using your services, even if they are paying customers? Do you have agreements in place with your users to cover those situations? Is there a way for end users to report to you what they see as spam or unsolicited content? How do you monitor customers activity to determine if they are bad actors?
You should have answers for those points if you want to build trust with end users
For prospective customers, we would most likely try to work with them to brainstorm use cases that are consent-based and non-spam. For current customers, if we do see that they're using our services for spam, we'll reach out to them asap.
Also, while we can't see the exact messages that our customers are sending due to encryption on our servers, we do know when a phone line is close to being banned from our health checks. When that happens, we'll reach out to our customers asap and learn more about what is going on.
This is a very simple integration and the fallback is also pretty straightforward to implement technically. What’s the differentiator? Why would companies use your product?
I'd say mainly scale and stability. While people can definitely do this on their own through Bluebubbles or custom Applescript, stability is difficult to maintain, especially at scale. For most businesses, iMessage is not the core product they want to think about and maintain. They just want a reliable API and support/team to talk to so that they can reliably integrate it as a part of their existing business structure.
As much as I want to applaud your progress here, as a user I want transactional stuff to stay in my email inbox. My iMessage is already starting to become overwhelming from spam and apps — I want fewer messages not more.
Yeah I agree. Our goal behind this is not to clutter up people's iMessage inbox with more transactional messages. It's to replace the SMS/RCS conversations that people are already having with customer service and scheduling agents with something more conversational and human.
iMessage is more conversational because it's what most people are used to using and seeing. People generally associate green bubble messages with spam/transactional messaging and blue bubble with trust. Additionally, iMessage also has additional features such as typing indicators and reactions (likes and loves) that makes the interface feel more conversational. WhatsApp could also be very conversational, but most people in the US use iMessage.
Reading your responses it seems like your angle is to fake looking like a human by using the blue bubble. Are you worried your users will ruin the trust of the blue bubble thus killing your product with your product?
My existence couldn’t possibly be any more digital, and I can’t remember a single time I’ve had a SMS/RCS conversation with customer service or a scheduling agent. I don’t want to have one either. My message inbox is already full enough.
My iMessages are for conversations with people that I actually want to talk to. The notifications are high priority because it’s with people that I want to talk to.
I can’t imagine my annoyance if I were to receive an iMessage notification while I’m expecting an important message, only to find that it’s more spam.
My email inbox is already a wasteland because of this. The absolute last thing I need or want is for the same thing to happen to iMessage.
That's why we're making sure that all of the use cases are non-spam and also of high importance to the user. As we've seen through our customers, an after-hour customer support agent for their apartment, as an example, could be a contact of high importance for the user and definitely not spam in their iMessage
> iMessage is intended for communicating with family and friends, and is not for conducting commercial activities or disseminating unwanted messages. iMessage misuse may result in service limitations.
We are not "disseminating unwanted messages". A lot of what we're doing (e.g. customer support or missed call text back) would be things that users would already be doing conversationally over iMessage.
You can't guarantee one of your customers isn't going to do that dissemination though, right? No spammer is going to sign up saying "I'm a spammer that just got banned from <other service>! Can you guys help?"
It's good YC is funding you because it acts as a later of protection from legal threats by apple. Hopefully if/when Apple litigate this I hope you will fight and set precedent for commercialisation of adversarial interoperability (A digital human right).
I suggest you implement Baileys also to your service so it can also be done with WhatsApp so we can accelerate the inevitable litigation.
How does this work? Do you have an agreement with Apple to connect to their iMessage service? If you do then kudos thats a real differentiator.
However if you're hosting your own mac mini farm and running bluebubbles or other such things that are not approved by Apple what is your plan to handle the case where you're sending enough traffic through Apple's services that they disable / ban / block you?
If its the former then awesome but if its the latter then Im not sure I'd want to depend on your service knowing that apple could ban you at any time.
Apple wouldn't ban us since we're not doing anything that would qualify as spam or abuse. Even if that hypothetical event does happen, we have SMS/RCS fallback systems in place so no conversations get stopped or lost
> Apple wouldn't ban us since we're not doing anything that would qualify as spam or abuse
Hmm, I wouldn't be so certain about that. Apple can ban you for whatever they like.
As someone who has been in the messaging industry for more than a decade, it sounds naive to think that the litmus test for whether Apple will ban you is whether your traffic qualifies as spam. There is a long history of people trying to get around A2P spam filters / fees / traffic limits / onboarding / KYB requirements by running business messaging on P2P pipes, like you are doing. Some of it has been successful (see Twilio in the early days) but the industry has gotten a lot more sophisticated around this stuff and is not going to be receptive to your approach, which to me resembles the SIM farms that are a scourge when it comes to consumer fraud and abuse.
Much of what you mention in your post seemed spammy; messaging regarding cart abandonment, etc. I aggressively label messages like that as spam, and I suspect others do too. I also suspect after blasting out messages like that, your accounts will get burned.
We work with our customers to make those messages consent-based and feel non-spam.
Could you elaborate? What does that mean in practice?
So far what I’ve seen from your service seems to be yet another attempt at blurring the distinction between bots and human interactions, which is generally used for spammy content
We're working to bridge the interaction between humans and bots so that automated conversations feel more natural and comfortable for the end user. In circumstances where the user can't reach an actual human (e.g. off hours support), they're often faced with bots over SMS/RCS that feel non-conversational and therefore can't support them in the right way due to interface. We're working on building agents that can more comfortably interact with users during those situations.
> Apple wouldn't ban us...
To me this screams you haven't talked to Apple. Given how macabre they were towards Beeper Mini, I almost expect the same treatment for Chert.
Nonetheless, best of luck if you can pull it off.
Did the YC interviewers ask you about this risk?
Did they ask you about a bigger market you can move into?
There's no way this foothold will last. You're going to get massacred.
The ideas like this one are the rarest of the startup ideas you wish they don't become too successful as they are the target for exploitation by bad actors with ad dollars quickly.
They won't be able to say no to the money.
This doesn’t feel like something Apple would approve of. Are you concerned about them shutting this down?
That is the platform risk. Apple blocked Beeper.com for the same reason.
Apple doesn't inherently prohibit programmatic messaging. In fact, they actually developed Applescript for people to do that. What they are against is spam and abuse. Therefore, as long as we stay compliant and prevent spam, Apple is not necessarily against this.
How are your financial incentives aligned against sending spam? From this side, your words seem hollow and the typical viability of these businesses relies on sending spam.
They developed AppleScript for people to do this individually, at limited scale.
Push notifications, attached to an application or website, and controllable by a user on that basis, are the solution for corporate messaging at scale.
This will get you banned. It’s not a question of if, but when. Users will hit the report spam button. Apple will shut you down.
People don't report our phone lines to be spam because the use cases that we focus on are either mostly inbound (e.g. customer service, the user is the one who texts first) or warm opt-in outbound (e.g. form-fill text back or follow ups). Businesses want a better medium to communicate with their users and users want something more conversational and native to their messaging behaviors.
I genuinely can’t tell if this is naivety or willful ignorance, but at the end of the day, it doesn’t matter.
This is in direct violation of the terms of service, and Apple invests a lot of money in keeping iMessage clean of this kind of misuse.
They control the servers, the client, certificate provisioning, hardware identification, and user identification. They can trivially trace a registered account to the point of sale and the card and PII used to buy the hardware on which the account was registered.
You will fly under the radar for just as long as it takes to annoy enough of their customers that Apple brings down a massive ban hammer.
Are you telling me that the “report spam” button actually does something??!?!?!!!
Your messages on iMessage are private by default, so "Report Spam" is the only way for Apple to receive the message for spam review.
This is definitely going to get banned, and as a customer of Apple’s, I will be glad for it.
I don’t need more iMessage spam.
We're not encouraging spam with this. We're mainly focused on existing conversational use cases that's currently done over SMS/RCS. They can be more human and expressive when done over iMessage.
>We're not encouraging spam with this.
what you encourage and what actually happens are two different things, though. gmail does not actively encourage spam, yet most spam emails i receive are from gmail addresses.
you have to actively fight against malicious uses, like spam. "not encouraging" is nowhere near enough.
what systems/processes/safeguards do you have in place to prevent abuse?
I agree. We're not completely self-serve right now, so we get to talk with each potential customer and learn about their use case before onboarding them onto the platform. This way, we can prevent use cases that involve spam or abuse.
>We're not completely self-serve right now,
"right now", which implies that you plan to move to self-serve. and obviously manually checking in on each and every customer is not sustainable if you scale.
do you do periodic checkups now? hoping nobody lies during onboarding is risky, in an already-risky endeavor. have you thought about anti-abuse systems for when you go self-serve?
The last thing I want is an AI “thumbs up” or reaction over iMessage
For iPhone only users, so right off the bat your product is targeting 50% ish of a companies customer base. And the non iMessage people get a worse experience?
We have SMS/RCS fallback for non-iMessage devices. Also, in the verticals that we're targeting, the iMessage usage rate is a lot higher than 50%
Isn't this a direct violation of Apple's terms of service? You say you aren't spammy but at a certain point you will get banned. I'm not sure how YC funded this based on the platform risk alone but I guess these days they're throwing anything and everything at the wall.
We're helping to support conversational customer support agents that can help users better during off-hours and scheduling assistants that can interact with and understand user requests better than current models over SMS/RCS. This is definitely not just spam but instead the future of conversational 2-way messaging.
How is this any different then
https://blooio.com/ https://www.sendblue.com/ https://www.lindy.ai/ etc?
I will say I am the exact opposite of your market, I want absolutely nothing like this. In fact I'd prefer iMessage to allow ZERO programmatic interfacing.
While Blooio and Sendblue are more focused on B2C agents and sales, we're more focused on 2-way conversational business use cases such as customer service that require scale and stability.
Lol not true. Blooio also starts at $39 for shared and $98 for dedicated. Source: I'm the co-founder of blooio. https://blooio.com/
The $98 dedicated line is inbound only. A lot of our application comes in the form of warm, consented outbound.
We have that too for $195/line for 6+ lines. We also have a full API you can find it here :) https://docs.blooio.com
RCS fallbacks, Emoji reactions, typing indicators, even changing chat background
do you support iMessage app payloads?
Depends on the app payload. Reach out to our team and we will work w/ you! enterprise@blooio.com
A few ideas for you guys: 1. Apple already supports iMessage for Business which is intended to cover the use cases you are targeting. But the set up process is ridiculous (for example: https://help.webexconnect.io/docs/wxcc-apple-messages-for-bu...). It would be amazing to have "Vercel/Resend for iMessage for Business" 2. If you go the send blue route, please support iMessage app payloads. Send blue doesn't support that
Thanks for the suggestion! Yes, the setup process is extremely long and requires a lot of documents from the side of the business haha. It's definitely one of our goals to create the Vercel for iMessage for Business. Also, for the iMessage app payloads, that's an awesome suggestion! We can work on building that.
how is it possible to build this whole thing and not know there is a very rich first party api that does the same thing and more in iMessage https://www.apple.com/ios/business-chat/
iMessage for business has a very long and restrictive registration process, gray bubbles instead of blue bubbles, and is inbound only. We're democratizing iMessage for businesses that have good intentions on helping their customers more but can't afford to go through the long approval process.
> the blue bubble interface, typing indicators, and reactions made agentic conversations feel more human than ones on SMS/RCS
Would you mind detailing your reasoning why agents should feel humans, when they very obviously aren’t? Why should we want AI to impersonate humans?
we don't think AI should by any means to pretend to be human, and we are not trying to hide that an agent is involved.
What we mean is that conversation should feel natural and low-friction for the person receiving it. These interactions: blue bubble interface, typing indicators, and reactions will make it less like an automated SMS message and more like a normal messaging flow.
We are trying to make agentic communication clear, useful, and native to channels people already use!
What is your plan to prevent spam from bad actors?
How do you ban bad actors so they can't spam again?
Does a user have to initiate contact in order to have messages sent to them?
1. Since we're not fully self-serve right now, we can choose to only partner with businesses with use cases that are opt-in and non-spam. 2. If we find that one of our customers is using this for spam, we'll reach out to them asap and determine next steps 3. Not necessarily. We support both inbound (user texts the phone line first) and opt-in outbound (we text the user first) use cases
And what would be the next steps? Would you block them from using your services, even if they are paying customers? Do you have agreements in place with your users to cover those situations? Is there a way for end users to report to you what they see as spam or unsolicited content? How do you monitor customers activity to determine if they are bad actors?
You should have answers for those points if you want to build trust with end users
For prospective customers, we would most likely try to work with them to brainstorm use cases that are consent-based and non-spam. For current customers, if we do see that they're using our services for spam, we'll reach out to them asap.
Also, while we can't see the exact messages that our customers are sending due to encryption on our servers, we do know when a phone line is close to being banned from our health checks. When that happens, we'll reach out to our customers asap and learn more about what is going on.
This is a very simple integration and the fallback is also pretty straightforward to implement technically. What’s the differentiator? Why would companies use your product?
I'd say mainly scale and stability. While people can definitely do this on their own through Bluebubbles or custom Applescript, stability is difficult to maintain, especially at scale. For most businesses, iMessage is not the core product they want to think about and maintain. They just want a reliable API and support/team to talk to so that they can reliably integrate it as a part of their existing business structure.
As much as I want to applaud your progress here, as a user I want transactional stuff to stay in my email inbox. My iMessage is already starting to become overwhelming from spam and apps — I want fewer messages not more.
Yeah I agree. Our goal behind this is not to clutter up people's iMessage inbox with more transactional messages. It's to replace the SMS/RCS conversations that people are already having with customer service and scheduling agents with something more conversational and human.
Why is iMessage "more conversational" than RCS? and "more human"??
I don't get the distinction you're making. I'm not an expert in mobile messaging so maybe I am missing something obvious.
And what about WhatsApp?
iMessage is more conversational because it's what most people are used to using and seeing. People generally associate green bubble messages with spam/transactional messaging and blue bubble with trust. Additionally, iMessage also has additional features such as typing indicators and reactions (likes and loves) that makes the interface feel more conversational. WhatsApp could also be very conversational, but most people in the US use iMessage.
Reading your responses it seems like your angle is to fake looking like a human by using the blue bubble. Are you worried your users will ruin the trust of the blue bubble thus killing your product with your product?
My existence couldn’t possibly be any more digital, and I can’t remember a single time I’ve had a SMS/RCS conversation with customer service or a scheduling agent. I don’t want to have one either. My message inbox is already full enough.
My iMessages are for conversations with people that I actually want to talk to. The notifications are high priority because it’s with people that I want to talk to.
I can’t imagine my annoyance if I were to receive an iMessage notification while I’m expecting an important message, only to find that it’s more spam.
My email inbox is already a wasteland because of this. The absolute last thing I need or want is for the same thing to happen to iMessage.
That's why we're making sure that all of the use cases are non-spam and also of high importance to the user. As we've seen through our customers, an after-hour customer support agent for their apartment, as an example, could be a contact of high importance for the user and definitely not spam in their iMessage
Assuming we have more customers using WhatsApp over iMessage, How did you decide to use iMessage over WhatsApp messaging?
we started with iMessage because it is still the most dominant, trusted channel in the US.
> iMessage is intended for communicating with family and friends, and is not for conducting commercial activities or disseminating unwanted messages. iMessage misuse may result in service limitations.
https://www.apple.com/legal/privacy/data/en/messages/
Seems pretty damn clear.
We are not "disseminating unwanted messages". A lot of what we're doing (e.g. customer support or missed call text back) would be things that users would already be doing conversationally over iMessage.
You can't guarantee one of your customers isn't going to do that dissemination though, right? No spammer is going to sign up saying "I'm a spammer that just got banned from <other service>! Can you guys help?"
Are you "conducting commercial activities"?
I like the idea of explaining things like "<brand name> for <brand name>"
Thanks, it felt like the clearest way to describe it haha
It's good YC is funding you because it acts as a later of protection from legal threats by apple. Hopefully if/when Apple litigate this I hope you will fight and set precedent for commercialisation of adversarial interoperability (A digital human right).
I suggest you implement Baileys also to your service so it can also be done with WhatsApp so we can accelerate the inevitable litigation.
We are def thinking a lot about interoperability and what it should look like in practice... >:)