While a UI layer is useful, and you can write useful application logic in JavaScript to run in the browser, sometimes an agent may want to automate some stuff while they are offline. Surely there are multiple use-cases where agents would create their own personal server with custom logic which automatically interfaces with a Holochain application (could even be an AI acting on behalf of the agent). Would be useful if Holo Hosts could run these for agents.
Does that make sense?
No, they can’t, but I really wish they could. I think the concern is that none of this stuff would be sandboxed, so app devs (or agents) could deploy all sorts of nasty stuff on a port. You could mitigate this somewhat by shoving all the app-land stuff into an LXC sandbox with very limited exposure to the host’s resources, and maybe future needs will compel us to add this to the HoloPortOS, but I wouldn’t hold my breath.
There’s also another even more serious concern, and that’s that an autonomous Node.JS agent on a HoloPort would have to be given access to the user’s private key, and that opens up the door for the HoloPort owner to impersonate the user.
Howevah! I could see a third-party service offering this sort of thing to users. Maybe it could create entries, hold them until the user comes back online, and get them to sign them. Or maybe the user would have complete control over the autonomous agent and put their private key right on the server.
There’s another interesting use case for autonomous agents that talk directly to a HoloPort: web servers with anonymous-level access to the DHT, getting entries and doing server-side rendering for the sake of search engines. SEO is currently a liability in Holo-hosted hApps, but I can see ways around this.
Surely it could be ‘sandboxed’ as much as a browser is a sandbox.
Hypothetically, if users of a HoloGrid hApp opened up their browsers running hc-web-client and just left the window open, one person in the network could use these browsers to do a fair amount of useful grid computing.
Call me crazy but maybe you could write a JavaScript/Python engine in Rust which runs inside a hApp instance. This runtime interprets receive() data as JS/Python/whatever and then dispatches the result to the original peer with send() again. Callbacks for days lol
