Most website content management systems would never get close to that size. If you need a bigger database, D1 is probably the wrong solution to begin with. 10GB can be millions of records depending on your table structure. But if you are gathering some survey data, running a CMS, etc. you probably should be fine with even just a few MB of data; which is probably the sweet spot for D1.
I set up a matrix server. Each OpenClaw agent gets its own bot user and room. I can @tag agents, invite them to rooms, and query them. I have one agent that has admin access to matrix and can create additional agents. WhatsApp kind of half works but it's tedious and flaky and you end up chatting with yourself unless you have a lot of spare phone numbers to create bot users. Slack flat out doesn't work because they've locked it down. Other things are available. But Matrix does the job and is straightforward to integrate with OpenClaw. Also great if you want to use this with multiple users.
I am but that is despite there being many very solid reasons not to. It's mainly painful until you sort out the many plumbing issues. This thread is going to be full of people telling you why not to use it. I'm not going to add more to that pile of great arguments except to acknowledge that, yes, it is super messy, insecure, dangerous, etc. I'm well aware.
So, why use it anyway? The promise of agentic workflows is very real. If you have seriously used agentic coding tools, you probably have figured out that in certain contexts it is a bit magical to see these tools solve real problems and do in minutes what would take you hours or days manually. It will also have exposed you to things like skills, guard rails, etc. that help you use these tools in a way that is a bit more repeatable and less prone to hallucinated outcomes. All this ports over well to OpenClaw. And in fact, you don't actually need OpenClaw as you can get most of what you are going to do in OpenClaw in agentic coding tools instead. Same models, same cli tools, same skills, etc. Try doing that instead if you don't want to go near OpenClaw.
OpenClaw only adds a few elements to this: 1) channels to communicate, 2) "agents" with memories and personalities in the form of markdown files and a feedback loop that updates these things out of the box. You can hack together stuff to add both to your agentic coding tools.
My company sells coaching and consulting services to people who are not programming that are interested in making a dent in the amount of digital drudgery work that they currently have to do. And because we sell it, I need to be able to actually do this. If you are a programmer you don't need our help. However, most of this planet is stuck with tools like ChatGPT that are very limited for this. There just are not a lot of good tools for these people yet. OpenClaw is a very rough, uncut diamond that if you get beyond its scary nature can actually do useful stuff. Tools will get better later. But right now, things just are going to be messy.
What I would recommend curious people: carve out some time to give this a serious try and don't give up too soon. Isolate it all you want. But focus on getting something useful going. You'll be solving lots of plumbing and configuration issues. And you'll need some imagination to make it do useful stuff because out of the box it's a bit useless and dumb until you make it actually do something useful.
Example of what I did recently that is useful and probably should be baked into the product.
Problem: setting up openclaw agents, hooking them up so you can talk to them, and configuring them is super tedious and fiddly in OpenClaw. Solution: an agent that does that.
How? For communication channels, I set up a new self hosted matrix server. Our company is now in there; we're ditching Slack. Because Slack is so locked down that it just can't really work for this. Matrix works really well for this. A lot of SAAS tools are locked down like this and finding workarounds is most of the work with agentic workflows. Replacing them is easier and the power move to make.
Synapse (the matrix server) has a cli and REST API. So, I created an admin bot user for OpenClaw to use that from an OpenClaw admin agent. That agent can create other agents, configure them with a model and a few other things. It gives them a new matrix bot user and hooks up a newly created room in matrix and then invites the team there. I didn't actually create that agent manually either; I made Codex bootstrap the admin agent for me. Because I used Codex to bootstrap the Matrix and OpenClaw vms for me earlier. So it had access already. Then I went on to create a few more agents with a few prompts. I actually made it rearrange my Matrix space and rooms as well. Because tedious and I just gave it access to that so why not. Yes, this involves giving admin access to an OpenClaw bot and this is scary.
We have a slide deck agent that uses reveal.js that you can use to prompt beautiful slides together. We have an SEO agent that figures out the right seo language for us to use and updates that regularly on our website. A competitive landscape agent that crawls a range of competitor websites to stay on top of what they are doing, what they are talking about, who they are linking to as customers, partners, etc. I have loads of plans for additional agents. We focus on agents that our clients would want to have so that we can get them going with those once they ask for that.
Once you get a few things like this up and running, this stuff becomes more useful quickly. It's still scary AF to give it access to all the stuff it needs. And you really really shouldn't. But it can't be useful unless you do. Classic security dilemma here. Throw out the baby with the bathwater or get things done now? Security often loses. And then people scramble to enable doing things in a more responsible way. I don't want to have to wait a few years for that to play out. But I recommend most other people to wait. It's the responsible thing to recommend. But if you don't want to, we can help you along the way and help you mitigate at least some of the risks.
Stuff like your fridge can use a fair chunk of power continuously and a small solar setup can offset that when the sun is out. Same with routers, chargers, standby devices, TVs, etc.
For a 800W setup, 4–5 kWh on a very good summer day is plausible. Over a full year, it's going to be something like 600–900 kWh depending on orientation, shading, and location. So in strong summer months you might get something like 80–120 kWh. But you won't be able to use all of that unless you have a battery.
However, A typical apartment in Germany is not using that much electricity. Roughly speaking, a one-person place might use around 160 kWh a month and a two-person place around 270 kWh. Finding a use for 20–30 kWh a month during sunny periods. That's how you get to 10%. 25% might be harder but doable if you could somehow have a battery soak up the excess power. I don't think there are a lot of plug and play solutions for that yet. But it should not be that hard to do technically.
Power in Germany is relatively expensive 160*0.40 is about 80/month for me. I pay a bit less than that because I use less power somehow. But still, that's is close to 1000 euro per year. Saving 100 per year means the whole setup would earn itself back in 2-4 years (most plug and play setups you find on amazon are between 200 and 400 euro). And depending on where you live you can actually get some of that back via subsidy. But it basically pays for itself even if you don't. Unless like me your balcony faces east and you only get a few hours of sunlight in the morning.
I spun up a self hosted matrix server a few days ago using codex, docker compose, and ansible. Stupidly easy to do now. I'm running it in Hetzner on a 3.99 euro/month vm. It backs up every few hours to a bucket and I have a few integrity scripts to monitor the backups actually happen. I did that because I was getting a bit frustrated with the flaky integration with Whatsapp and Slack in openclaw. I had it up and running in half an hour with only minimal prompting.
Whatsapp kind of works but you end up chatting with yourself and then open claw posts messages as you. Not ideal. You can't easily create new users (or bot users) in Whatsapp. It probably has some kind of bot api of course but I did not explore that much.
I never quite managed to get Slack working with open claw. I tried for a few hours. I think the Slack team is asleep at the wheel snoozing through this whole AI thing. If somebody there is still paying attention to things like this, maybe make some noise internally. Anyway, they made it stupidly hard to do anything productive via their APIs. The UI for managing permissions is a disgraceful hell of complexity. Add permission. UI freezes for fifteen seconds. Reloads automatically. Unfreezes. Add the next. And whatever you do, there's always one more permission you forgot. *end rant*
Relative to Whatsapp and Slack, Matrix is stupidly easy to integrate with open claw, codex, or whatever. We're retiring Slack now as I see uses for agent driven chat bots everywhere now and I want to get rid of any kind of friction around bot related plumbing. I have no use for platforms that intentionally cripple that or treat as a toll booth.
With Matrix, you just create a bot user manually or via an API. Set a password, get an access token and do whatever. No API limits. No faff with QR codes. No permission hell (Slack). It just works. Well documented API. End to end encryption. Etc. Create as many bot users as you need. Nobody is bean counting API calls, numbers of users, etc. Refreshingly easy.
Other OSS messaging platforms are available of course. I do not have a strong opinion as to which is better yet. But now I want a Matrix cli that can do admin, message sending, and all the rest. Probably already exists. But if it doesn't I might end up generating one. Macli might be a good name.
A requirement specification is how you prompt software engineers. One-shotting it doesn't work (waterfall). You need to put the SEs in planning mode. They will ask you questions and refine the plan. And you end up with a better plan. But if you make it too complicated the plan will go off the rails. So, you need to make them assign Fibonacci tokens to their planned tasks. Now you have a better plan and you can assign your SEs to tasks and get them working on it. Fibonacci tokens are not time units. This is very important. But you will run out of tokens after two weeks. So you need to buy some extra pizza tokens and make them work until midnight (crunch time!). That's how you get the job done. Every time. Sort of.
I bet some jerk is going to organize a multi agent scrum process at some point and burn some tokens on this nonsense.
That's what the coding agent does if you ask it to record a skill. Yes I can do that manually. But I'll get it wrong a few times before I get it right and waste half an hour in the documentation, if I'm lucky.
Or I just go, "I just created this cloudflare domain. Deploy the site via gh actions to cloudlare pages whenever I push to main. here are my credentials; put them in Github secrets." Or something similarly high level.
The clever thing here is not doing things manually but make sure you generate automation and scripts if you are going to do the same things more often along with skill files detailing how and when to call shit.
I think the issue here is less about AI misbehaving and more about people doing things they should not be doing without thinking too hard about the consequences.
There are going to be a lot of accidents like this because it's just really easy to do. And some people are inevitably going to do silly things.
But it's not that different from people doing stupid things with Visual Basic back in the day. Or responding to friendly worded emails with the subject "I love you". Putting CDs/USB drives in work PCs with viruses, worms, etc.
That's what people do when you give the useful tools with sharp edges.
I'd argue that back in the visual basic/Delphi day, there was a minimum level of competence needed AND, more importantly, apps didn't have as much surface area because they weren't exposed to internet
Darktable does a lot of things that are conceptually similar to what DaVinci Resolve is likely doing here.
One of the big things Darktable has been pushing for a few years is moving from the now deprecated display-referred workflow to a scene-referred one. The key idea is that you keep the image in something closer to the original scene as captured by the camera for as long as possible, instead of rendering it early into output-referred display space such as sRGB. With raw files that matters, because many editing operations behave very differently depending on where in the pipeline they happen.
That is a bit different from how tools like Adobe Lightroom tend to work. The main problem with display-referred workflows is not just reduced precision, but that you can end up clipping information and applying nonlinear transforms too early. Once that happens, later edits are working against damage that has effectively already been baked into the pipeline. So subtle tone mapping tweaks can push colors out of gamut, for example. There are a lot of ways to deal with that obviously and Adobe does a nice job of balancing tradeoffs. But they do remove a lot of choice and control from the process.
The UX tradeoff in Darktable is that module order matters a lot and there are a lot of different modules that do similar things in different ways. You can adjust modules in any order you like, but the processing order itself is usually best left alone. That is a leaky abstraction: it is hard to explain why the order matters unless you already understand what the pipeline is doing. And of course Darktable now allows reordering because there are sometimes valid reasons to do that. But that also means users can easily make things worse if they start changing the order without understanding the consequences.
But for simple editing, Darktable is actually really nice these days. I have some auto applied modules with rules for camera type and a few other things. Mostly it looks alright without me doing much. One of its strong points is rule based application of particular edits based on camera or lens. With my Fuji, it needs a little exposure correction because it under exposes intentionally to protect highlights for example.
I am a color science and image expert and couldn’t make heads nor tails of the dark table UI. I wanted to like it but it is just so horrible to use that I couldn’t stick with it.
It's easier to pile on a lot of changes with AI assisted workflows. And reviewing all that is definitely a challenge just because of the volume of changes. I've actually stopped pretending I can review everything in detail because it makes me a bottleneck in the process. Anything that makes reviewing easier is welcome.
To me, stacked PRs seems overly complicated. It seems to boil down to propagating git rebases through stacks of interdependent branches.
I'm fine with that as long as I don't have to deal with people force pushing changes and routinely rewriting upstream history. It's something you probably should do in your own private fork of a repository that you aren't sharing with anyone. Or if you are, you need to communicate clearly. But if the goal is to produce a stack of PRs that in the end merge cleanly, stacked PRs might be a good thing.
As soon as you have multiple collaborators working on a feature branch force pushing can become a problem and you need to impose some rules. Because otherwise you might end up breaking people's local branches and create work for them. The core issue here is that in many teams, people don't actually fork the main repository and have push access to the main repository. Which emulates the central repository model that people were used to twenty years ago. Having push access is not normal in most OSS projects. I've actually gotten the request from some rookie developers that apparently don't get forking to "please give me access to your repository" on some of my OSS projects.
A proper pull request (whether stacked or not) to an OSS project needs to be clean. If you want to work on some feature for weeks you of course need mechanisms to stay on top of up stream changes. OSS maintainers will probably reject anything that looks overly messy to merge. That's their job.
I spend more time in planning and steering the AI implementation than I do on reviewing it's outputs.
I do the obvious checks like tests and spin up a dev instance to make sure the feature works like I want it too, but very rarely am I reviewing every line of code these days.
reply