Live data from Hacker News

Clawdbot Renames to Moltbot

github.com

231–240 of 241 posts

Re: Clawdbot Renames to Moltbot

#231
post #221

Earlier quoted context omitted.

Really curious, what paragraph of the ToS is being violated?

Look it up. They have banned people over this and it was all over the news, some people cancelling their accounts etc

So the same is true if people use OpenCode with Claude Pro/Max?

Re: Clawdbot Renames to Moltbot

#232
post #9

The way trademarks work is that if you don't actively defend them you weaken your rights. So Anthropic needs to defend their ownership of "Claude". I'm guessing they reached out to Peter Steinberger and asked nicely that he rename Clawdbot.

Honestly the decision to name it Clawd was so obviously spectacularly stupid and immature that it makes me wonder about the whole project? I won't try it.

Re: Clawdbot Renames to Moltbot

#233
post #221

Earlier quoted context omitted.

Look it up. They have banned people over this and it was all over the news, some people cancelling their accounts etc

So the same is true if people use OpenCode with Claude Pro/Max?

Yes only the plan OpenCode themselves sells is „legal“ Opus.

Re: Clawdbot Renames to Moltbot

#234
post #183

Earlier quoted context omitted.

If you want iMessage you still need an always-on Mac, whether that's the main moltbot gateway, or the MacOS app running in 'node mode' to allow a moltbot gateway to use it to send/receive iMessages.

I noticed when I was reading Federico Viticci's post about it that he was using telegram, which has much better support for "markdown"-y rendering, which looks a lot nicer than iMessage. And then I thought to myself, why would iMessage actually matter? The only other use-case would be interacting with texts, but almost anyone can tell when someone is using an LLM to text - I feel like our texting styles are so person…

I see value in the LLM being able to read/integrate my iMessages since a lot of my scheduling/commitments are discussed on there.

Re: Clawdbot Renames to Moltbot

#235

Earlier quoted context omitted.

This is a dilution not abandonment issue. Courts will look at the level of systematic tolerance. If you have a history of vigorous enforcement, it will be harder to argue in the future that a borderline dilution should be allowed. If you allow borderline dilution, the court is going to consider what you have let other people get away with in the past. It’s a bit of a catch 22

I would still be interested in a real case where a trademark owner ignored a borderline case and this later resulted in an adverse ruling when a more concrete interest was at stake.

Amstar Corp. v. Domino’s Pizza, Inc., 615 F.2d 252 (5th Cir. 1980) The record showed a history of extensive third‑party “Domino” uses (including other food and grocery products). That crowded field made Amstar’s DOMINO relatively weak outside sugar, and Domino’s Pizza prevailed. Link: https://law.justia.com/cases/federal/appellate-courts/F2/615...

Re: Clawdbot Renames to Moltbot

#236
post #145

Earlier quoted context omitted.

The silly part is buying a $50 raspberry pi, then storage and memory and so on, when a $200 used M1 Mac mini is plug-and-play.

The silly part is buying a $200 used M1 Mac mini, when a $5 Arduino clone can be used to blink an LED. Oh wait—that’s the silly part

"What is my purpose?"

"You turn this LED on or off"

Re: Clawdbot Renames to Moltbot

#237
post #165

Earlier quoted context omitted.

If you have to mitigate the security issues but still use the product, how and what would you do about it ? to prevent prompt injection attacks and trifecta attacks. How to prevent gmail and iMessage leaks, if we cut off outbound access then it becomes useless , also it will spin up a reverse proxy like ngrok and send the data as long as it has inbound access. Once it has internet access its hard to prevent untrusted…

The only solution I can think of at the moment is a human in the loop, authorising every sensitive action. Of course it has the classic tradeoff between convenience and security, but it would work. For it to work properly, the human needs to take a minute or so reviewing the content associated with request before authorising the action. For most actions that don't have much content, this could work well as a simple p…

You might be okaying actions hundreds or thousands of times before you encounter an injection attack, at which point you probably aren't reading things before you approve.

Re: Clawdbot Renames to Moltbot

#239
I had a similar journey with Moltbot/OpenClaw. I spent a lot of time self-hosting and wiring things together reverse proxies, gateways, credentials, hardware decisions (Mac mini vs VPS vs mini-PC), and honestly the operational surface area gets large very quickly.

While researching ways to reduce that complexity, I came across PAIO. What stood out to me wasn’t just the convenience, but the architecture choices. The integration was basically one-click compared to the multi-step setup I had before, but the bigger win was BYOK and the privacy-first approach.

With self-hosted assistants, the tooling is powerful but the security model is often an afterthought, and it’s easy to accidentally expose something (as people in this thread pointed out with Shodan results). A managed layer that still keeps keys and data under your control feels like a reasonable middle ground between full DIY and full SaaS.

I still like self-hosting for learning and control, but for day-to-day reliability and security, having a platform that bakes in isolation and privacy primitives saves a lot of operational burden.

Re: Clawdbot Renames to Moltbot

#240
post #165

Earlier quoted context omitted.

The only solution I can think of at the moment is a human in the loop, authorising every sensitive action. Of course it has the classic tradeoff between convenience and security, but it would work. For it to work properly, the human needs to take a minute or so reviewing the content associated with request before authorising the action. For most actions that don't have much content, this could work well as a simple p…

You might be okaying actions hundreds or thousands of times before you encounter an injection attack, at which point you probably aren't reading things before you approve.

I agree, that's the main issue with this approach. Long-term, it should only be used for truly sensitive actions. More mundane things like replying to emails will need a better solution.
Post reply on HN