Plus you can get the model to write you a bespoke one that suits your needs.

I've been digging into how Heartbeat works in Openclaw to bring directly into Vibetunnel, another of Peter's projects

Australia and UK goes the full distance. Your full address: https://en.wikipedia.org/wiki/Driver%27s_licences_in_Austral...

Nailed it

Anything that can host Kubetnetes. If you are going to fo devopsy deployments might as well use the standard.

If you want it to be an alternative to shell history then ~/make.ts is better, since that'll be the same wherever you are.

Thanks, I haven't considered this! My history is usually naturally project-scoped, but I bet I'll find ~/make.ts useful now that I have it!

the coder's equivalent is not get paged (or bug reports). the system run's itself with no dramas, so I get to work on improving it.

A bit of shameless plug, I wrote 2 articles about this after doing the course a while ago.

https://martincapodici.com/2023/07/15/no-local-gpu-no-proble...

https://martincapodici.com/2023/07/19/modal-com-and-nanogpt-...

The way you worded tbat is good and got me thinking.

What if instead of just lots of text fed to an LLM we have a data structure with trusted and untrusted data.

Any response on a call to a web search or MCP is considered untrusted by default (tunable if you also wrote the MCP and trust it).

The you limit tbe operations on untrusted data to pure transformations, no side effects.

E.g. run an LLM to summarize, or remove whitespace, convert to float etc. All these done in a sandbox without network access.

For example:

"Get me all public github issues on this repo, summarise and store in this DB."

Although the command reads public information untrusted and has DB access it will only process the untrusted information in a tight sandbox and so this can be done securely. I think!

"Get me all public github issues on this repo, summarise and store in this DB."

Yes, this can be done safely.

If you think of it through the "lethal trifecta" framing, to stay safe from data stealing attacks you need to avoid having all three of exposure to untrusted content, exposure to private data and an exfiltration vector.

Here you're actually avoiding two out of them: - there's no private data (just public issue access) and no mechanism that can exfiltrate, so the worst a malicious instruction can do is cause incorrect data to rewritten to your database.

You have to be careful when designing that sandboxed database tool but that's not too hard too get right.

You definitely do not need or want to give database access to an LLM-with-scaffolding system to execute the example you provided.

(by database access, I'm assuming you'd be planning to ask the LLM to write SQL code which this system would run)

Instead, you would ask your LLM to create an object containing the structured data about those github issues (ID, title, description, timestamp, etc) and then you would run a separate `storeGitHubIssues()` method that uses prepared statements to avoid SQL injection.

Yes this. What you said is what I meant.

You could also get the LLM to "vibe code" the SQL. Tbis is somewhat dangerous as the LLM might make mistakes, but the main thing I am talking about hete is how not to be "influenced" by text in data and so be susceptible to that sort of attack.

Problem is if people are vibecoding with these tools then the capability "can write to local folder" is safe but once that code is deployed it may have wider consequences. Anything. Any piece of data can be a confused deputy these days.