I was trying to map ports for the JSON-RPC API from the Vagrant Virtualbox to my host system, but the connection kept being reset even though it worked fine from within after SSH’ing.
After finding these:
It seems the conductor code is deliberately bound to 127.0.0.1 inside the virtual machine to prevent external connections.
Does this mean it is expected to be used behind a proxy server, or should it be usable like a standalone binary most like cryptocurrency miners?
Oh hmm… I can’t say for sure (I am not active team member (but once was)) but I am feeling that is more unanticipated negative side effect than intended.
The comparison to cryptocurrency miners is interesting though cause I don’t really think there is much comparison to be made.
Apart from running Holochain within the Holo stack for Holo-hosting purposes, I don’t think it’s recommended to run Holochain as a server for remote connections. The point is to run it locally on all the edges of the network right. Because if you make it a public end point, you have to handle authentication, and Holochain only has light touch aspects for that so far, not serious authentication over those endpoints.
The idea may be that it is run by many stakeholders, but there is no going around having users that just use a web app, which may be hosted by any Holochain node (or do all nodes form a swarm and provide ‘torrent’ hosting like Zeronet?). This would be similar to users visiting blockchain explorer websites, run by organizations that connect to a blockchain network on the backend. In those cases it is obvious that when visiting those websites you do not connect directly with the network clients, and that to provide such a service, the organization will need to deploy centralized infrastructure.
In order to have a Holochain “Conductor” support multiple users simultaneously interacting using it, it will need to have multiple “instances” of a single DNA, configured for different agents, who in turn hold/have different private keys.
generally speaking, I think of a Conductor only supporting a single agent, not authenticating multiple users who can then act independently.
“or do all nodes form a swarm”
I would say it works like this, yep
I think we’re talking about different things. With ‘user’ I do not mean ‘agent’. With ‘user’ I mean end user. Someone who visits a website that uses Holochain as storage/business logic layer. Someone who uses the website and its services without running an agent themselves.
With Holochain, end-user = agent. That is, each person (and bot) who wants to use an app would normally have their own conductor (Holochain app server) and UI (whether web-based or otherwise) on their own machine. I think that Art and Eric, the creators of Holochain, consider it an anti-pattern to have one agent servicing activity for multiple users.
Of course, that’s not always feasible. That’s why Holo Host – but even then, an end-user = an agent; it’s just that their node is hosted on their behalf by some other machine, who bills the app publisher just like AWS bills Dropbox.
if you want to run holochain on a linux box with reverse proxy so you can connect from another machine… you could find a web-server-like solution to do that… or a quick hack is to use socat:
socat TCP-LISTEN:8889,fork,reuseaddr TCP:127.0.0.1:8888
where holochain is for example running on 127.0.0.1:8888
and the LAN machine for example connects via port 8889
(i dont think this hack currently works with Tryorama)
I wrote a script which simplifies some of the socat business:
hc sandbox ...
Described in more detail here: