Hi! I am quite new to holochain but read what I could.
If I understand it properly, in the current arrangement the conductor and the holo infrastructure runs on a dedicated and resourceful system eg. holo port, cloud or onprem hosted server. The apps and zomes are downloaded into the browser and run as WASM executables. I understand that at this stage of the product it is more than enough to have one technology stack fully support app development.
However, while this architecture satisfies decentralization data-wise, it still needs “miners” - systems that are resourceful - to host the core infrastructure. Which eventually leads to centralization - resource-wise if I can say so.
According to the promise of a truly distributed system, where every node is responsible of their own data and validate some of the others - the current architecture and the introduction of a specific hardware (holoport) does not seem to point into that direction.
My apologies if I misunderstand the situation and please correct me if I am wrong.
I would be happy to see the infrastructural parts of holochain being able to be compiled and linked to a native mobile app as libraries. Creating a pluggable architecture is easier with WASM and it also simplifies code validation - I get that. Maybe there are other ways to address these issues when the whole app is also linked together with the same binary. Since every hApp has its own network, when hosted by a mobile phone, the infrastructure would very unlikely host more than one hApp. So it would really make sense for me to link everything into one app.
Is there anything in the current roadmap that leads to these features? Is there any existing solution that I can experiment with in order to use holochain as a native mobile app?
Any feedback is appreciated, thanks.
1 Like
Hi @danleis
Holoports are not necessary. They are a convienence for being a host for Holo (which is different from Holochain).
I have successfully managed to run a holochain app on a raspberrypi 4. I believe this is good enough for decentralization. I wish it could run on a esp32 but holochain needs a 64-bit architecture for security reasons.
As for Native mobile, it is not ready as holochain doesn’t compile for android yet. Hopefully it will be in a near future.
4 Likes
Thanks for the answer!
I am looking forward to hearing more about the Native compilation for android.
1 Like
I’m SO ready to start developing for Holochain once this is figured out. Getting mobile conductors figured out (running natively, not the whole thin-client thing again) is nearly the entire point of Holochain to me. Increasingly, “cell phones” are the primary computer of many citizens, which is actually fine because they are only getting more powerful (and energy efficient vs PCs!). Even if Holochain is expensive to run at first, let’s just get that working and worry about optimizing it later.
This is one of the only threads on Android/mobile conductors I could find, so I’m replying to stuff brought up in the other related threads too.
I finally have an unlimited data plan for dirt cheap, something that was not possible years ago. This isn’t available everywhere in the world, but nothing is. Let’s see what we can do without worrying about data usage for now!
Battery usage is probably better to focus on, but I personally do allow a few heavy background processes to run on my Android phone at all times - they just provide that much value! Getting it working is a priority, then we can see how draining it is and worry about “wakeup intervals” and such.
The persistent notification thing is a red herring - a user can completely hide the notification (this is how Tasker recommends it) and then you’re back to normal. Also, in modern Android it’s only needed as a “just in case” the system feels like killing it - but a well-resourced device can actually have background processes doing work without needing a persistent notification. If the system does kill the Conductor, it probably is a good thing - we’ll get the conductor right back when a holochain app is opened again, in the mean time the user needs those resources elsewhere (or the system needs to save power/ram to stay alive). We simply need the conductor to be designed for graceful recoveries! Finally, the notification and any other workarounds is only needed until Holochain becomes indispensable to everyday Android users - eventually it will just be a feature of the OS, with root access, like Google Play Services!
The App Store problem is temporary too, for the same reason. Once Holochain is proven and widely depended on, the conductor can be made as an exception since it’s not a normal app. But for now, getting on the Google Play Store is not necessary! Everyone can (and should 
) download F-droid for free and have it running on their device in a minute or two. For now the conductor can be published to just F-droid and maintained/upgraded from there - good enough! Or even manually downloading an APK from the website.
Let’s just get this working so that us cross-platform developers have somewhere to put our data when it comes to the mobile side! 
3 Likes
Hi all,
since this topic has been discussed in other few threads I would like to list here the other references I found:
since in the above threads, service workers were mentioned, I’ve put there also some docs about it.
have a nice day!
1 Like
Holochain currently uses resourceful systems like HoloPorts to host apps, but the goal is full decentralization where any device, including mobile phones, can participate. Right now, native mobile support isn’t ready, but it’s something planned for the future. For now, you can experiment with browser-based apps (PWAs) or containers. Keep an eye on updates as the tech evolves toward more lightweight, mobile-friendly options.
2 Likes
