Hacker News Reader

Comment by yazzku | Hacker News Reader

It was obvious from their "key note" in day one that this project was a scam. The best thing that can happen to it at this point is for it to be sued and shut down.

Anybody can string a couple of API calls together and write an "app". That is not programming, and this project is a massive undertaking for somebody of their skill. It should have never gone to market to begin with, regulations should have stopped it on its feet. The fact that they put more effort into their "key note" than the actual product was already a red flag. It's like some marketing guys got together and decided that they were going to "take the world by storm with AI".

> we have internal confirmation that the rabbit team is aware of this leaking of api keys and have chosen to ignore it. the api keys continue to be valid as of writing.

Yeah.

View on HN

If claims from this[1] video by Coffezilla are to be believed, the r1 is not their first questionable project.

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

The r1 is not just not-their-first, it's a pivot that reuses code from their earlier endeavours. (which itself is fine, like, that's what you'd expect from a pivot, it's just that their PR strategy relies on claiming those past projects are wholly unrelated.)

When they rug-pulled GAMA (after selling a bunch of NFTs), as consolation prize they "open sourced"[0] a few things.

One of their many promises was that their space-station "metaverse" would have "Quantum Engine AI Integration" (letting you talk to NPCs, among other things). They released a lightly edited Unreal Engine game template (the "metaverse"), along side a file named `api.yml`[1] which documents an AsyncAPI[2] API (the "AI integration"). There is no actual integration, the API spec is just positioned adjacent to the Unreal project - there's a note in the README that amounts to "integrate it yourself".

The back-end component was never open-sourced, and they've long since shut down the API server, but based on the docs, the API used by the r1 is clearly a direct evolution of that design.

As for the R1's API, there is no documentation, but I partially reverse-engineered it and wrote some docs of my own[3], which is enough to see the similarities.

[0] https://github.com/gamaspacestation/

[1] https://github.com/gamaspacestation/gss_release/blob/main/ap...

[2] https://www.asyncapi.com/

[3] https://gist.github.com/DavidBuchanan314/aafce6ba7fc49b19206...

I swear all these shitty startups need is that clean look from Teenage Engineering to sell worthless garbage.

I have bad news about most SaaS products.

I mean that is definitely programming. The real distinction you’re looking for is the gap between programming and building a production-ready product.

I see no benefit in being pedantic. Obviously writing code that performs simple API interactions is "programming". The definition of programming is extremely broad.

It is rather clear to me that yazzku is saying that the programming required to pull of what the R1 does falls well below what Rabbit promised their customers. That this is such a bullshit design that we can infer that the entire product is a scam, because if they were serious it wouldn't be so obvious that no work into actually making a useful product.

You can build perfectly fine products without programming anything at all. The problem isn't the lack/scale/type/complexity of programming. The problem is that the product is bad, and this is not a pedantic point at all.

Please don't cheapen professional expertise in this way. The product is bad, yes, but why? Because the programming is bad, and the programmers are negligent.

> Anybody can string a couple of API calls together and write an "app". That is not programming

Yes it is. Simple as.

Please don't gatekeep something as casual as writing code. Good lord.

Casually writing code and writing code that securely handles customer data and maintains availability for something you're selling are two different things.

Imo it's programming, but not engineering.

And it plays, in large part, why some engineers get upset when programmers call themselves engineers without the skill, discipline, and responsibility to back it up.

To me it has nothing to do with size or complexity. You can have a 20-line well-thought-out imperative Python script that is well-engineered. And you can have a 200,000 line Java app that leaks PII all over the place, loses user data twice a week, and is impossible to debug because it's a giant spaghetti rats nest.

Reply on news.ycombinator.com