It seems that hApps run symmetrically (the software is the same on all participating nodes).
I’m wondering what kind of machines run holochain software in practice. Is it personal laptops and mobile devices or stationary servers? If participating nodes are on mobile devices, I’m curious how the DHT would work and how nodes communicate in a P2P manner when they are connected via networks with NAT.
The most common devices currently are personal laptops.
Re: mobile, there was a discussion about this recently on the DEV.HC discord (let me know if you need an invite):
pauldaoust — 04/04/2022
Here are some challenges I think we’ll face with Android integration: * Holochain wants to always be running, so that agents can sync with each other to replicate and validate data – providing both data redundancy and an ‘immune system’ that spreads word about bad actors. But Android doesn’t like long-running processes, because battery life * Metered data – the demands of participating in a P2P network could create some big $ costs for participants on expensive data plans, esp in countries w/o ubiquitous LTE and unlimited plans I’d love to hear your thoughts on these challenges. I think our plan is to use Holo hosting for mobile – think of it as ‘Holochain-as-a-service’, where storage and syncing are offloaded to a distributed network of hosts, so the phone device doesn’t have to be part of the network. (If you’re familiar with decentralised crypto, key management is ‘non-custodial’ – keys are stored on the user device, and the host can’t commit anything to the user’s write journal w/o getting the user’s signature.)
Yasharpm — 04/04/2022
1.Here is what I think about the continuous running problem:* I can think of 2 solutions: 1. For ongoing processes you need to publish an “ongoing” notification. Fortunately Android allows narrow non-intrusive notification presentations which helps with the UX. 2. You can still periodically run a service for short durations. Maybe some modification to how the underlying structure works so that the restarting is fast and light, help keep the node in sync. So everything can still be seamless. Here is what I think about metered data: You can detect the type of network the user is on. It is possible to distinguish between Wifi, 4G/LTE, 3G/edge. So different behavior can be coded for different conditions. On the wifi you can do whatever you want. On 4G only syncing the data and skip other security communications. On slower nets not do anything at all. We can also have a settings section which user can choose or even apply rate limits. What makes me more concerned is actually battery use. On the wifi when the service is continuously running, battery would drain in a noticeable manner I expect. I believe that’s the main reason Android guys limited the running services. So periodically coming online syncing the data and going back of is more appealing to me. You don’t want to keep the network in use.
@Yasharpm yes, battery drain is one of the concerns I have with an always-on service – and I wasn’t even thinking about needing to keep the WiFi on! I like the idea of running the service for short durations – that’s sort of a wake-up, call a hook function in the app, then sleep again, right? I feel like I saw that in the Android dev docs. I could certainly see that working if we made changes at a lower level. Secure Scuttlebutt does this well – they use a pull model of gossip rather than a push model, so as long as enough peers are online and always listening for requests to sync, then the system runs smoothly. SSB does this through ‘pubs’ – peers who follow everyone who follows them, so they act as moderately decentralised providers of high availability. Because of this, it was easy to create mobile SSB apps like Manyverse without killing the battery. I think it’d be a bit tricky, right now, to do pull-gossip in Holochain. We just changed the neighbourhood algorithm so that people only gossip with people to the left of them (clockwise around the DHT). Formerly your neighbourhood spread out to both the left and the right, which meant that you would push to and receive from the same general group of peers. That would’ve made it easy to ‘pull’ as an active process rather than simply listening for pushes. Now, the people you push to will never be the people you receive from, and in fact you won’t know the people you receive from until the first time they try to push to you. To my mind, that makes ‘pull’ unworkable – for now at least.
- [14:38]
Another option: I wonder if Holo hosts could also be used for ‘availability-as-a-service’ for networks where people install Holochain on their own devices (whether mobile or laptop/desktop). I’m urging the Holo architect to consider this as a business offering (cuz I think it would help with hApp usability). This, in addition to zero-width neighbourhoods for mobile (so they don’t have to receive any gossip) might help. While I do agree with your worry about centralised failure points, that only applies when you’re an end-user using Holochain, because while there’s a 5× redundancy for the hosts who host for you, all the traffic goes through a reverse proxy (on Cloudflare, so it’s geographically distributed at least, but still, I get where you’re coming from). With my idea of using Holo hosts to compensate for all those zero-participation mobile users, it would at least sidestep the concerns about centralised failure points (as long as enough hosts were participating) because hosts are just regular peers within the DHT – they just communicate through the internet, no Cloudflare involved.
- [14:38]
Thanks for the insider advice on Android; this is good stuff to know.
- [14:39]
I also like the idea of a Holochain ‘service’ that works for all hApps. Could it be a ‘required’ dependency? Can you do that with the Play store? That would seem to simplify the trickiness of passing over responsibility to app B if app A got uninstalled.
- I also like the idea of a Holochain ‘service’ that works for all hApps. Could it be a ‘required’ dependency? Can you do that with the Play store? That would seem to simplify the trickiness of passing over responsibility to app B if app A got uninstalled.
Yasharpm — 04/04/2022
It can be made available on play store. The way the underlying code works for when you want to use Google maps, or analytics or any other Google services is that they first check if Google play services app is installed. Then verifying that the SDK version is compatible with the app version. In the end it either seamlessly works or you get notified to install or update your play services app.
- [14:45]
Google play services is the only application on the device which is allowed to have an ongoing process in the background. I guess Google also cheats by making sure updating it is the highest priority.
- [14:46]
Note that all the push notifications also go through Google Play Services app.
- [14:48]
Sorry I don’t know what Holo hosts are. I still need to clear some time to learn Rust and practice happ development! But maybe silly suggestion: What if you keep a list of everyone who gossiped to you. So you can pull from them later?
- [14:49]
(when the app UI is in the foreground, the node can be running normally)
connor — 04/04/2022
@Damien has looked into holochain on android (as I have a bit at a much earlier time)
1
But maybe silly suggestion: What if you keep a list of everyone who gossiped to you. So you can pull from them later?
Yeah, I was thinking about something like that. It would require you to keep your listening port open for a while, so it wouldn’t completely eradicate the always-on problem, but once you’ve got a solid view of the people to your right… (edited)
- [15:02]
or maybe that could be part of the bootstrapping process – being given a list of peers not just to your left but to your right, if you ask for it
@connor @Damien if you guys need any help on this, I would love to be of assistance in any way I can.
for myself, I’m not involved in any way at this point
I got some good feedback from a core dev about my idea of pull-gossip. He said that, if you’re taking responsibility to validate and replicate data, but you’re only intermittently online, it might feel like trying to do your part but it might be harming the network as a whole. So maybe it’s better to become a leecher and be honest and up-front so people know what to expect. Not sure how this works into things, whether heavier nodes would be okay with taking on that burden in all cases. Maybe that’s an argument in favour of Holo-hosted nodes…
5 April 2022
Holochain must work on mobile devices for it to actually be a solution for the future. Let’s find a way to make it work without host nodes! How about keeping a running service in the background? If you can tell me the general distribution of data use of a node, I can simulate one on an Android app and then we can see how much battery it actually takes and also whether the ongoing notification can really be annoying?
We can bring up a server that sends random data over the socket (with the simulated distribution) and an app that keeps an open socket to receive that data and also send random data as well. Then we can see the battery use. Most important is how long the quite gaps are I think.
My thought on this is:
If the hardware functionality that drives the private holochain data is not energy intensive, then the network of holochain may emit a signal as if it was an Entity Components system ticker. And we can pull and push zomes to conductors at set times. A sort of epoch as if it acted on N people at a time. Assigning work could be the .await person to confirm. Does this wheel have a broken spoke?
Come join the synchronicity of awaiting 15 minutes of data too much?
These are some great ideas, nevertheless, in my opinion, this will put more responsibilities on the holoports. I believe in the long term run, the sustainability & reliability of the data in the holohost network will really depends on the price of holofuel. If holofuel price crash then there will be also a crash in the data reliability in the holohost network as many people will shutdown their holoports.