25 comments

[ 0.24 ms ] story [ 56.9 ms ] thread
So they're making it use OCI images? Cool. Hopefully there will be good support for Podman.
> But NanoClaw isn't just my personal project anymore. Thousands of people are using it. People are running production workloads on it. Businesses are building on it. There's a real community now.

as OpenClaw and now NanoClaw became "enterprise", now we need a new FemtoClaw to pick up the indie/boutique place

Putting these NanoClowns inside a container will not protect you from all kinds of safety hazards.
For my version of the AI assistant, I used a Docker container and Unix permissions:

https://github.com/skorokithakis/stavrobot

All plugins run in one Docker container, but they're isolated from each other by different *nix users, so they can't read each other's files. That's much more lightweight, and you don't have to run one container per plugin.

Crucially, plugins can't read each other's secrets or modify each other's code. I even have a plugin configuration webpage that doesn't go through an LLM, so the LLM never sees your secrets if you don't want to.

I've been taking a similar approach with my own exploration.
(comment deleted)
Can someone explain the special sauce of the claws compared to just use claude.ai etc
Whatsapp api integration + cronjob

Thats it. Its just pets.com

Edit: although as a counterpoint to my cynicism, just the intgreations and deamon-ness can be a game changer if the user experience is good. Thats the critical thing. If you can actually delegate tasks to it and not worry about them then it'd be great. But if your gonna have to worry if its done properly, or that it would delete your emails, then it doesnt work yet. But the dream of a robot assistant is inviting. I just dont think the underlying AI is there yet

Use containerd , Docker is cancer.
Sensible, this broadens our hosting options.
I can't believe the solution is creating uncompatibile branch and forcing users to use cladue for resolving merge conflits. Why not bake in the dual compatibility?
See your not thinking with agents yet. You need to be more like me. I have claude chew my food and wipe my ass. Saves a ton of time
apple container is really buggy with networking
yeah i see it too i have openvpn on mac as host and container couldnt access to inet until i disconnect vpn on mac but point is to have different connections
I'm surprised that the developer experience around sandboxing on macOS is generally so bad. Seatbelt is in limbo and apple containers are just a pain to work with as some have highlighted in this thread
I’ve been building sandboxing for Claude code workloads. So I can let it run wild without breaking my computer. Originally I used docker, but I’m now in the process of jettisoning that, and switching to qemu.

For my use case I want ssh access and being able to use docker in docker. This allows for things like test containers and docker compose. You can get all of that working with docker. But you kind of have to fight docker the whole way.

NanoClaw might have different needs, and docker could work better for it, and I hope so for their sake. But I’m not optimistic.

I installed nanoclaw last night funny to see it here on HN.

It was easy to install it, and get it running. I could @Andy message it on whatsapp but after that it fell apart fast.

I asked it to login to Facebook and check my notifications, and it started saving credentials and random things in the repo as json files. And din't work. It was hard to even figure out what was happening and why it didn't work.

Then I tried messaging it again and it didn't respond to me.

These things are extremely brittle despite the enourmous amount of github stars. I think it's just normies starring things trying to get on the train unfortunately. The promise of an AI Jarvis is unrealized still.

You don't need to use OpenClaw, NanoClaw or any of these new variants. You can literally use Codex, Claude Code, Gemini, OpenCode for the same thing. The only thing that it is missing from all of them is the communication channels because none of them come with native communication tools like OpenClaw.

But this is not such a big deal.

I made an open-source lightweight daemon in Go that fills that gap. All it does is to provide the means to connect to popular messaging systems like Slack, Discord, WhatsApp, Telegram, etc. and expose this all through the CLI.

The project is hosted here: https://github.com/pantalk/pantalk

My personal realisation recently has been that the unix way is the best way. We just need to go back creating daemons and lightweight composable CLIs and let agents do their thing. They are increasing being trained to operate the command-line and they are getting pretty good at it.

It is truly odd in a way. You had posts here about Google managers or execs saying AI coded something solid in a few days what their own team were working on for months or years, or something along those lines. But people seem to ignore that creating a clone of your favorite "Claw" product seems like an ideal first project for the sea of mid or senior engineers that haven't dipped their toes into the vibe-coding ocean.

You have people talking about the tired topic of the lack of moat for AI businesses. But people should be calling out the moat that most tech businesses take for granted. Forget the moat that prevents other businesses, what about the moat that prevents your own users from creating your own product "from scratch"?

Shameless plug: https://www.supyagent.com - we basically want to give away the integrations for free. For Claude users you just need to run `supyagent skills generate` and you get all the integrations. Works well with cursor and codex as well, and if you want a UI to go with it that can be tinkered, just run `npx create-supyagent-app`
Lol production use case for apple containers on what cloud
TBH I'm not sure why there is a whole debacle around security with openclaw (obviously you should run it in a sandbox) and if it makes sense for these bots to tackle sandboxing themselves. Now I have to trust their sanboxing vibe code? If not, then I have to run them in another sandbox and deal with nested virtualization.
Ironically, the whole "claw" thing reminds me of the time everyone was scrambling to get on the container orchestration bandwangon.