Holochain Forum

How should Holochain service be used in a shippable app?

Hi guys,

this question arose in me when I was trying around with installing a hApp using the Admin Websocket API. First I was using a sandbox holochain service (side question: What is actually sandboxed when running hc sandbox?).

That way of running a Holochain service is for development and testing. So I moved on to simply running holochain and then found out about the conductor configuration file. A generated config file will use the user’s home directory for settings and the databases. Therefore I’d consider it the (or a?) global conductor.

Then I saw that holochain accepts a -c option so I thought I might as well create a conductor config local to the app that I’m building and point to it. I consider that a local conductor.

All that lead to the question of what are shipped apps using? The global conductor? That would mean that each app needs to start the conductor, figure out the Admin Websocket port and install itself. That would mean significant security vulnerabilities.

So a local conductor. Each app can have its own local conductor, can start it and run it with the databases in a separate folder. No security issue here. But wait, how is one hApp then supposed to interact with other hApps? That can’t be it either.

I found the article on how to ship your hApp and the forum thread on the future of hApp distribution. Holoscape had its last update a year ago - a long time in this dynamic space. The article is missing the images which indicates it’s not up to date either.

If someone would be so kind and point me to the current approach to bundling/shipping an app?

3 Likes

In Snapmail I ship the holochain and lair-keystore binary with it. In the electron code, it spawns the services and make calls to it. There is nothing much really.
A hApp doesn’t have to interact with other hApps, only with other peers with the same hApp.
To be fair, key and identity management is somewhat of an issue with this method if you want a persistent key/identity across multiple happs.

1 Like

Thanks for the insight, @ddd-mtl, very interesting!

With that approach every hApp would have its own holochain and keystore. What about integrations among hApps, would one hApp never want to communicate with another hApp? Thinking of a calendar hApp to integrate with Snapmail for example?

1 Like

Correct me if I am wrong, but I think that so long as the rust DNA part of the app is the same, whether it is integrated through launcher / other conductor or it is run in the standalone client with its own conductor, it will find other instances of the identical DNA and work as one network.

So integration with other happs are totally doable even though there is also a standalone release and preferable if you also want to maintain key management and identities and all that

1 Like