What hApps have been used in "real life" so far?

By “real life” I mean by people who are not just testers but are using the hApp for its intended purpose.

1 Like

Can I assume that all of the hApps listed in he Holoscape index are at least ready for use by real users?

As of today, that includes:

  • Basic Chat
  • holo.txt
  • Passthrough DNA
  • Acorn (which says it “has been used with dozens of team members on globally distributed teams”).

Any others?

Hi @bhaugen, so that’s an interestingly weird case, in which the apps that most people have used are the ones you listed plus some others that were built for holochain redux, but almost none of them work on RSM nowadays.

Acorn is a very good example of a very good first mvp that is ready right now for RSM, although that depends: what do you mean ready to use?

1 Like

I mean ready for people to use for whatever the app was developed to do, not just to test. Like, I understand that Acorn has been used by software development teams to coordinate their development efforts, which I understand was Acorn’s purpose.

And yes, I am asking about what works nowadays, not some time in the past.

I’m being asked about how viable Holochain technology is for economic network infrastructure, so something like Acorn is good evidence, and more evidence is better.

Mmm okey, so the thing is basically that holochain and holo themselves are getting ready. The trick with acorn is that it includes its own packaging, which I guess is temporary until the official ones from holochain work.

We are going to have two stable release processes. In holo, people will upload their hApps and they will be accessible from a browser. In holochain, we are going to have binary for all OSs that shows up as a system tray icon.

Until those things are ready I don’t think we can say that “things work”, as in, you cannot show this working app to somebody as evidence… However, there are a number of projects that are getting ready for that moment. In the community there is an effort to build a mutual-credit library that shouldn’t take too long to be ready.

If you want to show something already working, you could also try the compository experiment (link to the forum post)

1 Like

Thanks again for your insights.

I try never to be in a hurry. I’m just trying to give a couple of interested outside people a realistic idea about the state of play.

I conclude, coming along nicely, but not quite there yet…

1 Like

I’m in a similar position. I have several use cases I want to build. There are people around me who are willing to play different roles of a team, and we are aligned in the intention to build what one might call self-sovereign applications.

My job right now is to evaluate the viability of Holochain: Can we use it? Will our efforts be accelerated by using it, or would we be better off building our own trimmed-down protocol? I hesitate to invent our own for obvious reasons. Especially looking with respect at all the effort that’s gone into Holochain. But there is an intrinsic cost to learning all of the particular terminology and architecture of a new paradigm. I’m trying to understand what building blocks I would need in order for Holochain to be viable for my use cases. Currently my list is:

  • Identity - This seems like the intention of DeepKey, but does it have a user interface? How can I demo it? I want my users to be able to create and manage their identity in a standard app. My litmus test is that this should be as easy as KeyBase. And in my app, they should be able to build from that same identity, or create a new identity that’s 1 to 1 compatible with the standard app. This creates trust and a tangible benefit for using this platform - i.e. create the last login you will ever need (and breathe a sigh of relief).
  • Some kind of chat example - Sounds like this is happening with Elemental Chat, but only for HoloPort owners. It seems really crucial that we have an app that demonstrates basic communications, that we can pick apart and understand the components of. I think this is at the heart of OP’s question.
  • Node Deployment Recipe: I have a kubernetes cluster sitting behind me. Lucky me. Can I install Holo on that? Or Holochain?
  • Client Node: I want end-to-end encrypted data. Offline-first capability. And I want to rely upon the DHT to synchronize data between devices. Is this possible? Is this even compatible with the Lair/DeepKey approach? This might be the deciding factor for me, because I feel it’s my top priority to deliver to end users, and if it’s 2 years down the road for Holochain, I don’t think that will work for me.
  • Mobile Node: Ideal, but I can deal with web for now.
  • App Deployment Recipe: So we don’t have our own app store yet. Ok. And we’re not doing mobile yet. Ok… so how do I go from working Nodes to a hosted hApp on the web?

I’m open to participate in creating these pieces and filling in the gaps where necessary. But trying to understand how large those gaps are and what my ROI looks like. What drives me is the problems that end users face, and the impact that data ownership and privacy will have on their lives. And that’s the objective I want to reach expediently.

I share this to ask if this resonates with Holochain team and community. I see some intersection with the Holochain Roadmap but:

  • Personal Identity is looking kind of far away (and not something I want to reinvent)
  • Currently the onboarding process involves reading a lot of scattered documentation from various stages of the Holochain evolution
  • Not sure if these primitive “lego blocks” that I want to build on are actually present and stable…

Any thoughts on how far away these things are? What’s in active development? And where can I help?

[edited to clear spam censorship]


@guillemcordoba @pauldaoust I’m not sure the answers to bitmason’s questions. Can you help?


The best way to get a good answer is to ask a good question, which you did!

I used to work for Holo and left to start my own business and build hApps, so I’ve done many things. I’ve experienced what’s possible and not possible for myself. Sometimes in the process of suffering breaking changes things that were even possible went back to being impossible, but we are getting over the worst parts of that I hope/think.

Working through Sprillow for Harris-Braun Enterprises we’ve been building Acorn for 2 years, keeping pace with Holochain. Just 9 days ago we created a release that is the most complete and usable version of the software yet, after not releasing for close to a year.

That version contains many of the parts you mention, though not all. It tackles the question of ‘deployment/release’, identity (in a way), chat, and ‘client node’ in your list.

We release as an Electron application rather than serving through the web, since Holochain itself is persisting data to the persons computer disk storage. Given that the UI is written for web though, it should be very viable to port to Holo Hosted once that’s an option.

Offline first capability is no problem since Holochain runs on device, and the system doesn’t block when no internet connectivity exists. It will sync when peers are found. That’s the notion of the ‘eventual consistency’. Offline first is really mostly a question of how well and how resilient you built your application UI at that point. Also lots of UX questions around that.

For “chat”, it’s not a primary focus in Acorn, but we do have all kinds of realtime collaboration affordances built in which basically correspond, and in one case, that of what we call the ‘Expanded Card View’, which is where you open a “Goal” as a card like overlay over most of the app, and within you can click ‘comments’, and within that section you will see comments stream in realtime, acting basically as a chat feature. For this we use the ‘signals’ feature of holochain, which is basically the ability to do realtime 'push’ing of info to peers, without waiting for a response. See this for example (this is working with Redux style state management in our React based UI)

Identity is managed by Acorn independently from identity would be managed in another Holochain application, because no other identity service such as deepkey is ready yet. This would be a huge ‘nice to have’, but doesn’t necessarily represent a barrier in the meantime. This just means you have to create a profile when you sign in, however, given that identity is private key / public key, one doesn’t have to create a password which is really nice. (For an extra layer of security it would be possible to prompt the user for a password with which to encrypt their private key, but Acorn doesn’t at this time)

As a personal note about development, I have found the use of both javascript + rust within the Holochain ecosystem challenging, as they’ve not been kept in sync 100% of the time and Holochain struggles with good developer communication about changelogs, semver and breaking changes. For this I’ve been finding it easier to now write unit tests within Rust itself as well, and limit my use of the holochain javascript libraries as much as possible. Rust has such great type checking that it’s hard to mess up if you just pin/lock dependencies.

I hope this helps with your assessment, it’s my hope to get more people in to Holochain and working with it.


Thank you for your response, and thank you for the open source work you are doing on Acorn! This is amazing, and exactly the kind of example I was looking for. I had no issues getting the app running on Manjaro. I’m going to dive in here with some questions! Feel free to answer whatever you have time for.

  1. Is uniqueness enforced on the username? I see the validate function is commented out.
  2. How do you handle simultaneous edits? I assume you lean on the CRUD actions provided by Holochain… how easy was it to work with these data types and present the current state to the user?
  3. I assume (like me) you’re waiting for DeepKey in order to support adding and syncing multiple devices owned by the same user… and account recovery and all that fun stuff.
  4. Did you have to do anything for peer discovery? Or did that work pretty much out of the box? I’m curious how Holochain peers find each other efficiently without a central registry.
  5. UX questions for an offline first app - affirmative. Totally aware that this is wild west, and there will be unique challenges as well as exciting opportunities.
  6. Javascript + Rust not in sync: Acknowledged. Thanks for the tip! I see in actions.js you’re using hc-redux-middleware which seems to be deprecated. If I understand correctly, you’re running your Holochain DNA/Conductor in a separate process and then calling out to it on localhost. If you were to do this through Rust APIs instead, what would that look like? Would you just expose custom HTTP/websocket endpoints to the javascript?
  7. What has made you successful/productive working in the Holochain ecosystem?

Thanks again! I’ll be continuing to study your application code. It’s great to have a complete example targeting RSM.

[edited to clear spam censorship]


Great to hear it worked on Manjaro, that’s not something we tested.

Let’s see…

Uniqueness isn’t enforced in a hard way through validation, which interestingly is a very difficult maybe even impossible or nonsensical thing to do, however, we had decided to naively prevent collisions by letting you know in the UI if another user that you have awareness of has used that username. we then prevent you, but that won’t ultimately prevent two users from both using the same username. Probably in the UI we should just change it to a notice to the user that the username is used already, but not prevent them from using it as well. This should be the standard in distributed systems. You already have your public key as your universally unique aspect of your identity so you’re fine.

Also very naively at the moment, there’s no type of reconciliatory interface, there’s just that it will show the latest edit as indicated by the timestamps on the Holochain headers of each ‘update’. Yes, we use the CRUD features, except we custom implement a ‘get latest’ since that’s that seemed to be necessary for the assumptions our UI makes.
This functions returns the hash of the original entry but with the latest values: https://github.com/h-be/acorn/blob/main/dna/crates/dna_help/src/lib.rs#L142-L188

There is an alternative to my version written in a more generic ‘hc-utils’ crate maintained by holochain that you can use in your zomes, should make things fairly easy. https://github.com/holochain/hc-utils/blob/develop/crates/hc-utils/src/get_latest_entry.rs

So, all in all, setting up basic data types and current state can be done quickly, and you can get more interesting with it if you want with more work.

Yeah, for sure

It’s all pretty taken care of, but you can get more or less sophisticated with it. First of all, since everybody is liable to have NAT issues, it’s good to use proxies… right now we hard code which proxy all the peers will use, but we can easily make it configurable per user, so they can have freedom to choose, which would be the p2p way. That’s just for allowing incoming connections tho, the discovery part is handled more centralized at the moment, although the source code and option for people to run their own “bootstrap” server exists as well.
Here’s where in my stack the bootstrap server being pointed to is configured: https://github.com/Sprillow/embedded-holochain-runner/blob/main/src/config.rs#L16
and here’s where the proxy server being used is configured: https://github.com/h-be/acorn/blob/main/conductor/src/main.rs#L37
Those services are both ones that happen to be being run by Holo, but I figure I have the technical knowledge I could set either or both of those up myself or specifically for Harris-Braun Enterprises and Acorn as well. Personally I think they’re hitting a nice mix of freedom and simplicity at the moment. There is also local network ‘MDNS’ style networking that’s possible, but right now it’s one or the other which isn’t cool. More advanced config will come I think

Don’t follow your entire question but re. hc-redux-middleware yes the one on holochain org is deprecated, but I use one that I spun off, but don’t have in a great state for widespread use yet. I haven’t prioritized making it really friendly and up to date. https://www.npmjs.com/package/connoropolous-hc-redux-middleware
I do use the main websocket interfaces that holochain can expose… there are two types of interfaces that holochain can run, both over websockets. One is admin and one is app. my javascript client connects separately to both, yes via localhost, on two separate networking ports. The admin interface let’s you install new DHTs/DNAs and the app one let’s you call your exposed zome application functions. You could abstract the interface in Rust and write a layer in between to make those calls, but that might just be making a lot more work for yourself, when the interfaces exist.

connecting with other developers through the forum, and occasional video calls organized by community devs or Holo organization and Holochain developers.
tracking along with development progress in the holochain/holochain repository, and other repos in the github org, watching pull requests and the interactions around them, and sometimes even leaving a basic level code review if something glares.
not rushing to be on the bleeding edge. I used to struggle with breaking changes, now I am more patient and I will always prefer to wait and see something land more fully / stably than adopt it at the very first chance. This saves extra time/effort in terms of constantly updating, and let’s me focus on application logic.


Thank you for sharing your learnings and approach!

I asked these questions specifically to dig into some of the harder aspects that I know present unique challenges in the distributed space. Your answers give me a good sense of present state - what I will have to work with and design around.

Back to the test lab for me! I will keep prototyping and learning the basics. And at some point I’ll share some of my analysis and experiments.

How do I find the “kasra” group on discord?