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.
receive() data as JS/Python/whatever and then dispatches the result to the original peer with
send() again. Callbacks for days lol