Parallel tool calls do not work for my scenario. I can't ask a copy of my agent a question about something until a dependent call has resolved.
Tool use that changes the mode of the environment is a good example where you cannot go parallel. I've built a recursive agent that can run a Unity editor and I can't just blindly run whatever it wants in parallel or combos like SwitchScene -> GetSceneOverview won't interleave correctly. You'll wind up with 15 calls that loop over every scene and then you grab the overview from the last scene you switched to 15 times.
There are ways to hack around it a bit, but at some level the underlying narrative does need to be serialized or you'll be wasting an incredible amount of resources.
Depth-first search doesn't guarantee the best solution, but on average it's guaranteed to find a solution faster than breadth-first search. It's worth waiting for those dependent calls and going super deep if you want some reasonable answer quickly.
It obviously requires a lot of figuring out (by better men than me) but it seems a worthwhile adventure.
The halting problem can just be figured out experimentally in production. Users might need to earn or lose privileges over time as things escalate. Admins might approve a script and allow running it without prompts or pressing the button.
Perhaps entire applications can be written this way. I much enjoyed old php code with discussions in threaded comments. (The cache will save us.)
Or sending Content-Security-Policy: script-src 'none' for everything that isn’t intended to be a document. Or both.
IMO it’s too bad that suborigins never landed. It would be nice if Discord’s mintlify route could set something like Suborigin: mintlify, thus limiting the blast radius to the mintlify section.
I imagine there’s a fair amount of complexity that would need to be worked out, mostly because the browser doesn’t know the suborigin at the time it makes a request. So Sec-Fetch-Site and all the usual CORS logic would not be able to respect suborigins unless there was a pre-flight check for the browser to learn the suborigin. But this doesn’t seem insurmountable: a server using suborigins would know that request headers are sent as if the request were aimed at the primary origin, and there could be some CORS extensions to handle the case where the originating document has a suborigin.
> I wonder why are dofiles have to be on remote machines?
Because the processes that use them run on the remote machines.
> I type an alias, the ssh client expands it on my local machine and send complex commands to remote.
This is not how SSH works. It merely takes your keystrokes and sends them to the remote machine, where bash/whatever reads and processes them.
Of course, you can have it work the way you imagine, it's just that it'd require a very special shell on your local machine, and a whole RAT client on the remote machine, which your special shell should be intimately aware about. E.g. TAB-completion of files would involve asking the remote machine to send the dir contents to your shell, and if your alias includes a process substitution... where should that process run?
Yes but but does the process have to read from a file system dotfile, instead of some data fetched over a ssh connection?
> your alias includes a process substitution
Very valid point. How about a special shell only provides sys calls and process substitution on remote, the rest runs on local client, and communicate via ssh?
I understand this will make client "fat" but it's way more portable.
> Yes but but does the process have to read from a file system dotfile, instead of some data fetched over a ssh connection?
Well, no. But if you didn't write that program (e.g. bash or vim), you're stuck with what their actual logic is. Which is "read a file from the filesystem". You can, of course, do something like mounting your local home directory onto the remote's filesystem (hopefully, read-only)... But in the end of the day, there are still two separate machines, and you have to mend the divide somehow, and it'll never be completely pretty, I'm afraid.
> How about a special shell only provides sys calls and process substitution on remote.
Again, as I said, lots of RATs exist, not all of them malicious. But to make "the rest runs on local client" you need to write what essentially will end up a "purely remote-only shell". Essentially, all the parts of bash that manage parsing, user interaction and internal state tracking but without actual process management. Perhaps it's a good idea, actually; but untangling the mess of bash source is not going to be easy.
The current solution of "have a completely normal, standard shell run on the remote and stretch the terminal connection to it over the network" is Good Enough for most of people. Which is not surprising given that that's the environment in which UNIX and its shell were originally implemented.
Remote machines usually don’t need to know your keystrokes or handle your line editing, either. There’s a lot of latency to cut out, local customization to preserve, and protocol simplification to be had.
reply