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.
Especially when Apple has provided an approved path with iMessage for Business. If this isn't trying to send spam/abuse, which alone wouldn't prevent Apple from shutting it down anyway, it is trying to avoid the registration/vetting process implemented by iMessage for Business.
At least with Beeper the pitch wasn't to enable A2P but to allow real people to use iMessage alongside other platforms.
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.
It's not the "wrong" way, it's just different. iMessage works well for businesses that want to create a conversational experience in their customer service that conveys care and attention
I am sorry. Can one not a conversational experience using RCS? What, in specific, does iMessage do that RCS does not which prevents RCS from having a conversational experience?
I suspect you are actually implying something different than conversational experience or using it as a substitute for a completely different concept.
This impersonates a person on a platform which has generally prevented that... so people will be more likely to have a conversation, as they don't expect it to be a bot. The fact that they'll have to rotate out iMessage accounts so the message history will kill any possible gain from the deception.
What I don't understand is why a business would want to bifurcate their messaging stack... this is a solution that only works for half of their customers... for a business that doesn't have an app.
Even if your core offering disappears you can do the same thing that every other SMS-sending thing can do?
I also notice you answered the question, but not in the way anyone who needs to depend on this service would want to hear. So yeah you're doing the Mac Mini thing.
I'm with landl0rd. This service should not exist, you should feel bad for creating it, and every time I get a spam iMessage I will think about you and curse your name. Hope the money's worth it.
Not even the worst reading of their reply would lend to that implication.
It’s pretty obvious that they meant that anyone who depended on their service would/should probably run away kicking and screaming if they were looking for a dependable service that will do what they claim to in the long term.
If they were Apple sanctioned, then at least you’d have some reassurance that the service won’t die randomly one day when Apple has had enough, à la Beeper.
First, that's pretty obviously not what I said. Two things can be true. This is bad, and also if I were evaluating it for use in my business, it is obviously not something I can rely on.
But then just ...Um yes? I trust Apple to keep a handle on their iMessage network. Citation: having used iMessage for ~15 years. This would mean things like ensuring that I didn't get spam. Ensuring actual company identity (does anyone remember Messages for Business?) &c. This is pretty obvious and I am trying to understand your comment?
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.
Apple WILL ban you. You're not in some capricious walled garden. You're breaking and entering, and they'll destroy you.
There is nothing of value to build here. You should take the rest of the day off, then tomorrow, pivot entirely.
The folks here are trying to save you n years of hard work and wasted effort. Please listen. You're lucky to have a YC check. Apply it somewhere else, to some other problem. Preferably not in someone else's garden, and especially not in one where they shoot to kill.
Seeing that YC will even fund something as risky as this, I'm going to go ahead and late apply. I have a feeling I shouldn't write that as the reason though ;)
Seriously though, this is wild. How is this different from those click farms with a wall of phones viewing livestreams or tapping on adds or whatever?
There might not be space left? I know of a few companies that have already been admitted, and they're filling slots fast.
I don't know how much they budget for overflow.
Don't let me discourage you. I'm just following my own suspicions. My company is at a $2M run rate and I'm thinking I shouldn't bother applying since I missed the window.
(Dang, care to comment?)
I still want OP to make the best of their time in YC and their runway. There are plenty of other great ideas out there rather than being a freight train hop-on.
I agree, even if they decide to persist with this, they need to grow into a more robust business (ex. focusing on the abandoned cart followup niche) than just being an API that can get shut down overnight.
And yeah it's definitely late, but I'll just take what you said as a push to actually bang it out today and try to fight my tendency to write and say way too much on those kind of things, haha. It's only half tech related anyway, similar problem space as Firstbase.
I think what we're doing is fundamentally different from Beeper in terms of positioning. Beeper is trying to offer an additional interface to iMessage when it already exists for humans. What we're doing is giving agents the ability to interact with iMessage users, which is something that fundamentally can't be done on the current interface.
The fact that Apple hasn't banned agents like Poke is a good indicator that they're not necessarily against agents on iMessage.
Poke looks like a startup with a 2 month head start that's also unvetted in the market, not a case study of permitted behavior and success at subverting iMessage with agents. Does anyone know if Apple even knows Poke exists yet?
Likewise, Poke also looks doomed. They're creating... OpenClaw but worse. OpenClaw hype and interest has recently fallen off a cliff, I don't think the angels will be getting their money back on that one.
> giving agents the ability to interact with iMessage users
As an iMessage user I want the opposite. I’m happy for agents to contact me through the cesspool of telegram or WhatsApp - on those apps I expect it and am suitably on guard. I highly value Apple’s policing of their ecosystem so I know that when someone iMessages me I can trust they are who they say you are.
I’m curious and fascinated in the pitch for this startup and how you convinced investors that you could overcome the obvious hurdles. You must have some Travis kalanick level of “we will break the rules and it will just work out”. Hoping you pivot your talents to something I can root for.
What was the terminal app though and what was special about it that Ghostty didn't already provide?
edit: Found this one article (via google) that talks about the terminal. I guess it was a terminal that you could "prompt" to do things and it would figure out the shell commands.
If I recall correctly, warp is older than ghostty. Warp became popular because it was one of the well maintained rust-based terminals, and it had some simple AI features like completions and natural language command recognition. That’s why I started using it at least and I liked the dark theme better than that of any other terminal. I barely used the AI features initially but my company pays for it if I want to use it so I started using it occasionally.
Warp is older than ghostly and warp provides much more functions. Not only AI stuff but better editing of the shell (yea, I’m sure there is a way to get it in ghostty too), a built in run book where you can save commands (yes, you can say it should not live in the terminal)
Do you need all of them? Maybe not. Maybe. I used warp in the past (before AI) but now just Ghostty. But it required more customization to achieve just some of the stuff warp does.
- The _block_ system where you could navigate up and down without scrolling the whole buffer rigidly
- The tabbing system that actually works and doesn't feel clunky
- The command prediction
- The workflows (but that's now pretty much dead unless you really do not use AI)
I believe soon a day will come when the agents will chat with each other to get things done. Agents running on different machines, behind firewalls, on phones, laptops, servers etc will all want to chat with each other.
So there is going to be a need for Instant Messaging for AI Agents - Launching soon. https://agent-socket.ai
I noticed that too and did roll my eyes as well but I'm glad I kept reading - its actually quite a good article. Maybe the author used an LLM to help do some copy editing but should have probably given it less editorial agency.
Either way I'm glad I read it and waiting for the other parts of the series. Really curious how to get access to this airline booking data so I can write my own bot to book my flights and deal with all the permutations and combinations to find the best deal.
Same here—I tolerated the linguistic tics, I found enough meat to keep going, but it’s the conclusions that confuse me. And that feels like the intellectually dangerous part with this sort of LLM writing. For example:
> Convergent evolution is real. Every major GDS independently arrived at the same underlying platform. That is not coincidence — it is the market discovering the optimal solution to a specific problem.
I struggle to understand the claim that GDSes “arrived independently” at interoperability standards through “convergent evolution” and market discovery. Isn’t it something closer to a Schelling point, or a network effect, or using the word “platform” to mean “protocol” or “standard”?
Isn’t it like saying “HTML arose from web browsers’ independent, convergent evolution”? Like—I guess, in that if you diverge from the common standard then you lose the cooperative benefits—see IE6. And I guess, in that in the beginning there was Mosaic, and Mosaic spoke HTML, that all who came after might speak HTML too. But that’s not convergent evolution, that’s helping yourself to the cooperative benefits of a standard.
“The market” was highly regulated when the first GDSes were born in the US. Fares, carriers, and schedules were fixed between given points; interlining was a business advantage; the relationships between airlines and with travel agents were well-defined; and so on [0]. IATA extended standards across the world; you didn’t have to do it the IATA way, but you’d be leaving business on the table.
If anything, it seems like direct-booking PSSes (he mentioned Navitaire [1]) demonstrate the opposite of the LLM’s claim. As the market opened up and the business space changed, new and divergent models found purchase, and new software paradigms emerged to describe them. It took a decade or two (and upheaval in the global industry) before the direct-booking LCC world saw value in integrating with legacy GDSes, right?
…the LLM also seems bizarrely impressed that identifiers identify things:
> One PNR, two airlines, the same underlying platform.
> Two tickets, two currencies of denomination, one underlying NUC arithmetic tying them together.
> One 9-character string, sitting in a PNR field, threading across four organisations' financial systems.
> But in general, identifiers have little currency outside the system that generated them
That's clearly wrong, because if it were true we wouldn't be able to identify anything. Identifiers are only useful in so far as some external party assigns a meaning to the identifier. Two systems MUST pick a common idwntifier to discuss a person. They MUST pick an identifier to discuss a technical field. They MUST even pick an identifier to discuss a technical protocol.
Identifiers are everywhere. They'll usually be translated into something internal at the edge of a system, but I bet the PNR is too.
Most identifiers are for use within a system, and are not intended to be GUIDs, semantically. My name is Paul Davis, which functions well enough as an identifier within my lived community, but is pretty useless as "real" identifier for me, which is why other entities I interact with want my birthday, or social security number, or passport or ...
One can cheat on this for airline systems by taking the position that "the system" is the aggregation of all the different systems, not any one of them.
Interesting to note right at the start of the article that they sat on a plane next to each other in 1953 but the formal partnership between AA and IBM was not till 1959 - 6 years later! The article makes it look like all this happened magically fast but in reality a reminder that things take time!
>> is almost mythological. In 1953, C.R. Smith, president of American Airlines, was seated next to R. Blair Smith, an IBM salesman, on a cross-country flight. By the time they landed, the outline of a solution had been sketched. IBM and American Airlines entered a formal development partnership in 1959.
edit: oh and then the actual system didn't actually go live another 5 years later - in 1964. Over a decade after the two of them sat next to each other.
Reminder to myself when my potential customers don't sign the deal 5 minutes after my pitch!
So during the intermittent period IBM and American Airlines were focused on research of the problem.
The system was a based on a military messaging system.
What is important to note is before SABRE the system used was a sell at will until a stop message was issued. Then sales would be on request. This method is still used between different airline systems today.
Before the implementation of SABRE airlines used teleprinters as a way of communicating. Some of the commands SABRE and other IBM 360 systems come directly from this period. For example AJFkSFO9MAR was a way of economizing on characters sent. It means what is the available seats from JFK to San Francisco on the 9th of March. This predates SABRE.
There is several reasons that the System 360 (the reservation systems used by airlines like SABRE) is one that it is written in Assembler, and also the logic is very tied into its role of reservation. For example it was designed in the days of punchcards, which have a totally different method of matching than a relational
Database. The logic is still used on matching a seat to a fare.
On the pure speed much of it is gained by clever engineering tricks. An example would be the passenger record. This is 9 alphanumeric id of the passenger reservation. It is the hash of virtual memory location of the reservation.
It takes 4 cpu cycles to retrieve it.
Three women are sitting in a bar discussing their lovers, the first says, "My lover is a wrestler, he's so energetic, it's _wonderful_!".
The second responds, "My lover is a poet, he's so romantic and thoughtful and sensitive, it's like something out of a fairy tale!".
The third is silent, and the other two women look at her expectantly until she finally sighs and says, "My lover is an IBM salesman, he just sits on the edge of the bed and tells me how good it will be when we eventually make love."
I don't understand why claude code (and all CLI apps) isn't written in Rust. I started building CLI agents in Go and then moved to Typescript and finally settled on Rust and it was amazing!
claude code started as an experimental project by boris cherny. when you’re experimenting, you naturally use the language you’re most comfortable with. as the project grew, more people got involved and it evolved from there. codex, on the other hand, was built from the start specifically to compete with claude code. they chose rust early on because they knew it was going to be big.
While the LLM rust experiments I've been running make good use of ADTs, it seems to have trouble understanding lifetimes and when it should be rc/arc-ing.
Perhaps these issues have known solutions? But so far the LLM just clones everything.
So I'm not convinced just using rust for a tool built by an LLM is going to lead to the outcome that you're hoping for.
[Also just in general abstractions in rust feel needlessly complicated by needing to know the size of everything. I've gotten so much milage by just writing what I need without abstraction and then hoping you don't have to do it twice. For something (read: claude code et al) that is kind of new to everyone, I'm not sure that rust is the best target language even when you take the LLM generated nature of the beast out of the equation.]
Think about your question, depending on the tool, Rust might not be needed, is high level memory performance and safety needed in a coding agent ? Probably not.
It's high speed iteration of release ? Might be needed, Interpreted or JIT compiled ? might be needed.
Without knowing all the requirements its just your workspace preference making your decision and not objectively the right tool for the job.
While not directly related to GP, I would guess that a codebase developped with a coding agent (I assume Claude code is used to work on itself) would benefit from a stricter type system (one important point of Rust)
Yes, but if you put type strictness on a line, Rust would be further along I think.
Not to say that Typescript is bad or anything, but I would like to see data on my gut feeling that "stricter languages would make coding agents work better"
This is actually a curious one, I think you might have that gut feeling towards the compiler/transpiler ?
> Yes, but if you put type strictness on a line, Rust would be further along I think.
There are huge differences between build times, as we know, Rust likes to compile with effort, by design, it's important for the compiler to navigate all the nuances. Typescript with bun for example, can run a bit faster. Is the compiler making you think it's more 'type safe' ?
This looks really nice! Congratulations on building something awesome, especially in a space that's "crowded" with the big players.
I want to give kudos to two things:
1. It took you 10 months to build this. This is focused product development and craftsmanship which is very different from Vibe coding something. So let this be a reminder to all the "I can vibe code this or that in a weekend". Good products / experiences take time.
2. You've pursued building something in a space that anyone would normally dismiss right away: "Why would anyone use this? Google Docs/ Word etc already does this" or "MSFT / GOOG will destroy you". Good on you for picking something that is hard and building it well. I actually had this idea and almost built it but dismissed it myself for the same reasons as above. So reminder again for the builders in the back: Doesn't matter if there is a 800lb gorilla building this, if you can execute it better go for it.
> This is focused product development and craftsmanship which is very different from Vibe coding something. So let this be a reminder to all the "I can vibe code this or that in a weekend". Good products / experiences take time.
How do you know? There isn't a git repo that one can see the history of, he could have coded this in one weekend and used the rest of the time doing noncoding activities. Also, he could have made the entire thing by prompting without any hands on coding at all. The fact that it is a web app with a SaaS platform (the thing that LLM-assisted coding is the best at) doesn't inspire confidence.
I signed up and gave the product a spin and its clear that its not some vibe coded weekend project. Clearly a lot of effort has gone into it and OP also was clear that they've spent 10 months on this.
Thanks, that's nice. Yeah it's been 10 months, and 7 of them completely full time... living off savings. I think there's plenty of room for innovation with word processors now that we have LLMs and the big players are unlikely to go far outside the box.
Yeah, all of that was fun/tricky to figure out. I'm planning to start a little dev blog on Revise that will get into the weeds of how this stuff works - will share it on here when I get around to it. Too much to explain in a comment. Thank you though!
It’s an approach that works and I’ve thought of implementing the same thing but stopped short because I feel it just pushes the underlying problem around. Now I have to share my creds with a black box that I know very little about and it’s not a real vault.
This should be solved by the vaults (hashi corp / AWS Secrets Manager).
The one thing that I did build was based on a service that AWS provides (AWS STS) which handles temporary time bound creds out of the box.
It took me a minute to recognize this as satire (thank you HN comments). However it does actually make sense - maybe this could be a way for OSS devs to get paid.
What if we did build a clean room as a service but the proceeds from that didn't go to the "Malus.sh" corporation, but to the owners / maintainers of the OSS being implemented. Maybe all OSS repos should switch to AGPL or some viral license with link to pay-me-to-implement.com. Companies that want to use that package go get their own custom implementation that is under a license strictly for that company and the OSS maintainer gets paid.
I wonder what the MVP for such a thing would look like.
This site is not satire. You can actually pay on Stripe and it will create code for you. The site is written with satirical language but it is a real service.
I consider this a form of performance art. To really expose the absurdity of the system, you can't just point at the cracks; you need to actually stick your fingers in.
Yes it's even more effective this way IMO, we will probably see some 11/10 mental gymnastics from people condemning this and failing to apply the same standards to billions dollars corps.
Part of the point here is that the systems are fundamentally broken, more broken than they were before when we already thought they were broken.
Some people look at that and think "I suppose we should keep propping this system up as much as possible; the less propping the more immediate harm is caused to people/infrastructure/society".
The people behind this site/talk clearly don't buy into that. The way they see it, a reckoning must come. We might as well get it over with as soon as possible. Rip off the band-aid so to speak. So maybe we should shake the system and show that its falling apart.
I am only 50% certain that your idea is expanding on the satire, if not: project owners can provide dual licensing. I'm sorry if you are serious and didn't understand you.
After bogo-sort, it's the most badness-maximising "solution" I've ever come across. Why bother asking for the creator's consent to copy and run the original bytes, when you could instead ask for their consent to have a robot that no one understands and could potentially do anything read a few paragraphs of text describing what those bytes do, imagine how it might work, and try to build something resembling that from scratch, using a trillion or so times more energy.
// VibeSort
let arr = [51,46,72,32,14,27,88,32];
arr.sort((a,b)=>{
let response = LLM.query(`Which number is larger, number A:${a} or number B:${b}. Answer using "A" or "B" only, if they are equal, say "C".`);
if(response.includes('C')) return 0;
if(response.includes('B')) return -1;
if(response.includes('A')) return 1;
return 0;
});
console.table(arr);
The energy thing won't sail. A backhoe or front-loader uses far more energy than the equivalent human labor, but having higher energy solutions available is what technological civilization does.
Arguably Cowen's "Great Stagnation" was driven primarily by not embracing higher energy provision in the form of fission.
Copyleft was intended as a principle to keep the software free (as in 'freedom'). Proposing to lock out certain areas of the codebase is directly opposite to this principle.
LOL. Same here. But the footer disclaimer and testimonials gave it away immediately:
> "We had 847 AGPL dependencies blocking our acquisition. MalusCorp liberated them all in 3 weeks. The due diligence team found zero license issues. We closed at $2.3B." - Marcus Wellington III, Former CTO, Definitely Real Corp (Acquired)
> This service is provided "as is" without warranty. MalusCorp is not responsible for any legal consequences, moral implications, or late-night guilt spirals resulting from use of our services.
This site is not satire. You can actually pay on Stripe and it will create code for you. The site is written with satirical language but it is a real service.
This could work out great, because the OSS devs can focus on building their project instead of marketing to businesses, running sales processes, consulting on implementation and supporting the implementation. No need to find corporate sponsors either.
Lol so instead of paying maintainers who already built the thing you want, we instead charge you to use AI to make countless copies of maintainers’ work and direct the profits back to the maintainers? That sounds like true satire.
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.