Low code development for Holochain Apps

Hi everyone !

I am open sourcing the low-code platform Generative Objects I have been building over the last 11 years. I want to provide the tools to people to accelerate the creation of a new decentralized internet, and in particular Holochain applications.

The idea would be to have a way to model the application you want to create, and from there automatically generate all the code needed for the application to run. And have still a way to extend the application with custom code. This is already existing, this is the Generative Objects platform. What needs to be done is to connect it to Holochain.

As a similar example, I have recently connected Generative Objects to SOLID in order to fast build decentralized applications, here is a video describing this : https://www.youtube.com/watch?v=EgYuwMisd2s

You can also see a more in depth presentation of Generative Objects here : https://www.youtube.com/watch?v=Fg7xXf0kJdM

How do you feel of such a low code platform applied to Holochain ? Anyone interested exploring this ?

EDITED : You can also read a summary of Generative Objects story and my intention here : https://modeling-languages.com/low-code-open-source-platform-generative-objects/


I’m in love. :blue_heart:

Absolutely stunned! I feel like man should never have to code again, EVER! Having come from UE4 Blueprinting background, plus having seen your (and @philipbeadle’s and others’) work on visual and intuitive programming, it kinda sucks to even think of having to code again, knowing that it would pretty soon be obsolete… And I think that’s a great thing – coding getting obsolete – as it would free up some space in our brains to be better dedicated to designing better solutions and not having to worry about the implementation details. As for the implementation,

A few questions:

  • The blog said the data source can be plug&play, but what about the execution environment? How would it run on Holoports? Will you have to write a new plugin for your code-generator for transforming a GO (in your sense of the word; not to be confused with Golang) schema into Rusty Holochain DNA (h)app? I guess so… At least something along those lines…
  • How is it different from CRISPR (our Holochain CRISPR)? Don’t get me wrong, it doesn’t have to be different… [competition is always good from my (a consumer’s) perspective, after all! ¯\_(ツ)_/¯]
  • Where does one design exotic functionality? [And this I’ve wanted to know for CRISPR too, but @philipbeadle’s videos are just too intimidating for a noob like me!] For example, let’s say I wanna write my own custom Area(Circle) function that for some reason returns half the area of a circle. How do I write (pi*r^2)/2? Where’s the visual editor for coding functionality? Where’s the node-editor? Is it being worked upon? Or is it a use-case that better be coded by hand?

A few suggestions:

  • Why not skip User Interfaces and rather do one thing and one thing alone! 'Cause you (both G.O. and CRISPR) would never be able to design a sexy user-interface, PERIOD! It’s a lost battle – your battle with U.I.; why fight it then? I’d recommend you (both G.O. and CRISPR) throw user-interface generation into the bin.

Something like:

[Ohhhhh, pure nostalgia…]

1 Like

:scream: :scream: :scream: This is really wonderful @walter.almeida and I think that ‘low code’ is gonna be such a crucial component of Holochain adoption. I don’t know how the rest of the team feels, but for me, Holochain adoption isn’t the important thing — empowering teams to own their own infrastructure and moreover own the way their software serves them is the part that gets me really excited. So I see Holochain as answering the ‘own their infrastructure’ need and low-code as answering the ‘own the way their software serves them’ need. After all, the promise of empowering people to create their own groups with their own rules is a pretty thin promise if they always need a programmer to help them.

I don’t have any bandwidth to take on a new project, but I’m really happy to delve into the way GO and Holochain work and try to help you (and any other participants) figure out how to map the one to the other. That’s my job with Holo — thing explainer and developer mentor.


Thank @the you for your feedback !

To start, I must say that I am a very newbie around Holochain, technically speaking. I am aligned with the values and promises of the project, even invested in HOT coins (which is doing great at the moment!) and I want to be part and see how the technology I built could be complementary and supporting the fast creation and deployment of Holochain applications.

What I want to bring to the world with Generative Objects (GO) is the democratization of software creation and allow all of us to create, in a collaborative way, the platforms and services we envision for the future. With GO we could already envision a collaborative approach to creating platforms : let us users create our own platform that belong to all of us and thus decentralizing at ownership level. Plugging-in with Holochain would also add for decentralizing at a technical level. This is why I see a big fit in the 2 technologies.

About CRISPR : I don’t know it, I would appreciate a demonstration or some video to get a better idea of what it does. However, I understand that CRISPR is specialized for creating Holochain Apps. Generative Objects is broader range, and can be seen as a model driven oriented development platform, that allows to create any application metamodel and the associated code generation templates, in any target language. At the moment, the metamodel integrated in GO is for modelling entreprise applications (used for many enterprise scale applications), data-driven applications, with heterogeneous data sources. This is why we can integrate an Holochain connector and connect entreprise applications to Holochain data source, that would result in creating hybrid applications with a mix of Holochain data and classical data. The code generation templates are at the moment targeting HTML/Javascript single page apps, REST APIs and C# backend, but we could write templates for RUST code. We can also generate configuration files, deployments scripts, or whatever would be necessary, you name it.

So at the moment I could see quite fast the integration of Holochain for creating hybrid applications, if that makes sense. And with some more work, full Hollochain Apps.

For exotic functionalities, there are custom code extension points everywhere and design template for the front-end, that could be fully tailored.

There is no visual editor yet, it is all form-based, but to be integrated definitively. For custom code editing => the full generated code (and custom code) is pushed to GIT and we use a classical code editor for editing the code.

For the user interface : we are in the process to fully review the front end meta model to make it VERY flexible and allow a web designer to integrate all his/her fancy designs. And the plan is to integrate a designer such this one for example : GrapesJS

I need to leave for the day, but would be very happy to continue the discussion !


Thank you for welcoming me @pauldaoust, I need to leave for the day, will answer later !

1 Like

Hi @walter.almeida! You are hitting some strong chords here :slight_smile:

There is a lot of excitement already in the community about low code infrastructure. I can share these ones:

I’m mind blown by grapesjs, it seems so powerful and so easy to integrate with the things we are already doing. Thanks for sharing, I think I’ll be playing with it more.

I think holochain has a sweet spot in which you can make frontend elements coupled with zomes (backend modules) which are quite decoupled from each other, thus enabling big flexibilty and composability. Here you can find already “working” examples of different modules that follow that pattern.

Hum I’m not sold with the possibility of having end-users edit the backend code for holochain. It’s quite difficult to develop a secure application, in the sense that holochain itself doesn’t maintain data integrity of the data (eg transactions), but rather provides the tools for you to be able to code validation rules that will do that. Those rules have to be deterministic, and there are some constraints baked into that, that I don’t expect non-technical people to be able to grasp without an enormous amount of training.

So, my ideas circulate more around publishing decoupled small pieces developed by technical programmers that then non-technical people can compose and connect together to suit their needs. I think there is a lot of low-hanging fruit here, that we could explore without putting an enourmous amount of effort but rather reusing the work that other holochain projects are doing.

Also, holochain “deployment” is radically different to other architectures, in that there is no external service, server, or blockchain to connect to. What we could do here is directly target holo, in which we’d use chaperone to have the user login to the holo hosting infrastructure where a new instance of the desired DNA (or multiple DNAs) would have to be instantiated. It’s possible but adds some constraints to hybrid apps for example.

Like @pauldaoust, I’m always excited to play around these topics, so yes absolutely I’d be up to connect and explore this terrain :smiley:


I don’t know if I’m a suitable person to speak on behalf of CRISPR, but still… here you go:

It’s a rather old video, but for an overview, it should suffice.

Yeah, that’s all a Holochain app is; basically, just a bunch of Rust files (HDK-dependent), some Typescripts files (Tryorama), the Rust Config files (toml and all), and a JSON file (dna.json). It’s been a very clean code and dependency organization from the get-go (thanks to Holochain core devs), so it should be pretty easy to be template-able in your G.O. engine.

[The Holohcain build output is in Wasm; it would be great to have a BUILD button that first produces the rusty code on the fly, cargo-builds it in WASM, and finally assembles the DNA (with the DNA-util command) and optionally throws the generated code away (especially useful for prod-testing)… But I would be fine even without the BUILD button though…]

Yeah, saw in the video, Microsoft Visual Studio 20xx (also happens to be my favorite IDE environment I ever worked in)!


@guillemcordoba What a coincidence! Almost posted at the same millisecond!

But with people like Paul making understanding the Holochain system much simpler, and with all the effort Holo(chain) is putting in making it easy to develop with (not to mention the efforts of Low Code Zome), I think things will only get better, and that with time more and more ‘everyday’ people (with no prior experience in programming whatsoever) will be able to develop full-fledged secure Holochain (h)apps. In fact, I think ‘normal’ people (non-programmers; as though programmers are somehow abnormal; haha) will find Holochain very intuitive to develop on (thanks to agent-centricity); it’s only us programmers from client-server, microservices, or blockchain backgrounds who have to reframe our whole mental worldview in order to comprehend the Holochain-way.


Mmm right but… With validation rules as well? I have a hard time picturing that, in the sense that even us programmers have a hard time with those… You need to know at least these concepts:

  • What’s a hash, entry, element
  • How a DHT works, with eventual consistency in the mix
  • The difference between local source chains and remote neighborhoods in the DHT wrt validation
  • Timestamp reliance: which local time are you going to trust?
  • Update mechanisms and resolution callbacks
  • Link metadata non-determinism
  • Partition and offline cases

Yes, you could argue that you can build a wrapper kind of language around these to hide complexity and allow only certain mechanisms, and provide the tools by which they can do trial an error to train themselves (I’m brewing things around this as well). I don’t know how far we can go with these, and what I’m pretty sure about is that we don’t begin here, as in, this is not the low hanging fruit with which we bootstrap the process and the conversation.

My hopes are much higher in CEPTR, with things like this, minute 6:40.


just amazing!!! several of us have formed a dev team commons to build Ceptr-like concepts (or possibly CEPTR itself). we have extensive knowledge of the Holochain architecture and will also have a Rust study group. I sent you a DM but wanted to post publicly so the core team and others can see what our plans are :slight_smile:

love your enthusiasm for this and would be very excited to discuss collaboration. either way support for Holochain and Happs/devs is our main goal! :purple_heart:


This feels good, thank you for proposing your help. What I feel I need to understand more are the scenarios of usage of Holochain and the kind of applications that are main target. For instance : does creating a new decentralized social network with Holochain is a typical use case ? And are we going to fully decentralized applications with 0 servers and all peer to peer ? or having still infrastructures but on which people and groups can take ownership ? Any pattern / best practices to handle the consolidation of data when data is no more centralized but distributed amongst peers ? I have delved in SOLID a bit, how the two technologies compare ? These are the kind of questions I am having. Thank for support so that I can fast grasp all of this and get into Holochain !

1 Like

Thank you, I will have a look at all this, to make myself an idea of what already exists and how we could complement.

Yes indeed, feels amazing. I haven’t tried it yet but it has been on my radar for a long time to integrate visual design to GO. If you explore before me : I would be interested if you can share how it was :wink:

Feels great. What seems new to me is to hear about backend elements for Holochain. When I got introduced a year ago I understood it was supposed to be fully serverless. Is backend development new ? To be honest, I believe some level of backend capability is necessary to build truly scalable and performant applications, this is why I don’t fully buy the fully serverless approach of SOLID. However I see you talk later about no servers with Holo, so I would need to understand how backend functionnality is actually achieved with Holochain, I must be missing a piece.

Indeed. Same for GO and classical client server dev : I believe that the end user can model the data, the screens, simple workflows but there is a need for a developer to tackle the most touchy part. However I believe it will change and it is coming in a few years that end users will be able to build everything, thank to proper, well designed low code platforms

The way we work with GO is actually to build full applications with a team composed of end users and developers, knowing that Low code allows to have much less effort put in actual technical development. And for common technical components, they would be integrated in the templates used to generate code from the functional model. These templates are definitively written by developers, but have to be coded once only (and then maintain if necessary)

Is there any resource to refer to where I can grasp this and how it actually works ?

Yes ! Thank you for your interest and support !

1 Like

Yes indeed, I believe it would be too much effort to completely remove the need to write technical code at all. As some of the technicity can be better and faster expressed through actual code. If we can already generate 95% of the code, then this is already amazing ! And with time we can cover (or not) the extra 5%

However, it feels important to have a flowing / integrated experience for both modeling and code generation and custom code writing, If fact the technical code becomes an integrated part of the application model. So that it is very easy to model, generate, add custom code, go back to model and regenerate etc. without having extra manual synchronization / integration time that would time consuming, boring, and not error prone.

Also, it is important that the end user can actually model and generate a fully working application, autonomously and with no support of a technical person, and then ask help to a developer to write the missing parts. And for the developer to very easily be able to connect to the app model and do his extensions. This is what we intended to do, and did with pretty good success with Generative Objects

1 Like

Thank you for the invitation @pqcdev, I am definitively aligned and I am in :blue_heart:


Wow, lively conversation in this thread since last week! I’ll try to respond to all the things I can…

Sounds like a great typical use case. Holochain is meant for any kinds of application that revolve around multiple humans interacting with each other, so that would naturally include:

  • social media and chat
  • electronic medical records
  • supply chain
  • collaborative knowledge management (wikis, etc)
  • project/task management

I see lots of promise in the idea of a ‘community building toolkit’, where people just download all the components they need and use it to bootstrap their own community. Philip (creator of Chimera Builder) shows off this idea in this video, where he demos an app called Community Builder https://youtu.be/Y60cmE3rZZs . I don’t want to get too far into the weeds re: my favourite use case of Holochain, but I do want to underscore why I think Holochain is such a good match for small, tight community spaces, and it addresses this question too:

Holochain can empower anyone to build their own community network with its own shared data store, without any special IT knowledge, completely free of servers.* This lets them be in charge of their own stuff, rather than delegating control to some big cloud company (let alone even knowing that’s what you have to do if you want to set up a community space online).

* While Holochain is technically fully P2P/serverless, the reality of the current internet is that people will probably need a couple ‘helper’ services just to punch through NAT gateways and discover each other. There’s a proxy service which performs the same functions as a TURN server, as well as a bootstrap service for locating enough peers to get a good-quality introduction to the existing network. We run instances of both of these services, but people with enough IT experience could also set it up on cloud servers.

A group holds all their data in common – the distribution among peers doesn’t mean Alice can’t access it if it’s stored on Bob’s node; it just means Alice, Bob, and friends don’t have to store a copy of everything on their nodes. That said, data discovery is hard when meaningful information hides behind an opaque hash :slight_smile: There are patterns for making data discoverable, mainly using links from well-known hashes (e.g., ‘anchors’ whose value is hard-coded into the app and is easy to calculate a hash for). Using patterns like these, you can easily create table-like structures, even going so far as being able to create indexes.

Solid and Holochain both model data ownership around the individual, and they both use linked data as their basic way of organising information. The big differences I see are that, with Solid, your data stays in your ‘pod’ and an app (e.g., social media app, hospital’s EMR software) is an external thing that asks you if it can access your pod. With Holochain, on the other hand, your data and your app are inextricably linked – the app defines what meaningful information should look like, both app and data live on your machine, and data is shared publicly either by denoting it as public (in which case it gets published to the shared data store) or by granting selective access to it in a Solid-fashion using getter/setter functions that access your device’s private data. Hope that makes sense – I feel like I’m coming into this conversation from the wrong angle :slight_smile:

When we talk about backend in Holochain, we’re usually talking about a microservice-like binary that lives on every user’s device. Everyone has a copy of the backend (the ‘holochainy’ part); everyone has a copy of the frontend. That means their own data is immediately accessible, but it does probably create performance issues for some sorts of applications. I’m curious to see how Holochain’s graph model might be ‘hacked’ to provide the same sorts of speedy lookups on public/distributed data that centralised databases offer. Do you have specific examples of performance issues you’re concerned about?

The closest thing I can think of is this application architecture intro (skip the part about donuts; I don’t think it helps clarify anything :wink: )

I’m super excited to see this conversation unfolding; looks like there’s some fruitful dialogue going on

@dcatki pinging you – keep this on your radar for a future Low-Code Zone episode!


Ceptr Network Intelligence | Ceptr would alleviate this, no?

even without a downloadable OS you can design a neural network Happ DNA to live inside a bundle just like a nucleus to keep track of which info needs to be more readily accessible. smart receptors VMs can manage data and track flows…

linking to the UI is maybe a bit messy but thats where OS comes in. but then again I know literally nothing about front end but am gonna start learning some React. possibly this is where the cool stuff that Phillip and Walter have built will come in… idk :man_shrugging: lol

1 Like

I love the idea of AI doing “the heavy lifting” of moving the top layer of code above the boilerplate around to make Happs (remember Happ > dapp)

really I see it as each fractal membrane is more like a dapp of specific features and we could make a UI for “drag & drop” choices ie person designing clicks a drop-down of 10 choices, which could be done for several options of functionality

1 Like

I’m not sure – my grasp of Ceptr is pretty weak, and it’s been three years since I read the whitepaper, but from what I recall Ceptr is just a pattern for distributed computation based on a few ideas:

  1. data should always have meaning associated with it (that is, it should be information, not just data)
  2. if I don’t understand data, I need the code that can turn it into information
  3. data and code can both be nested/fractal/tree-like
  4. code is like DNA; it forms the ‘rules’ by which an organism plays and can be replicated
  5. those who are running the same pieces of code should be able to communicate with each other like a multicellular organism

Holochain tackles #4 and #5, and partially #1 and #2 too. The innovation that Ceptr brings is the interesting data structures that make #3 really easy. So I don’t think it have any specific tools that help make data lookup speedy.

While I definitely see the benefit of such a building toolkit, it also has its limitation, and is king of the “old” way (yet on decentralized and new tech) of creating systems by composing blocks, which is the fundamentals of many configurable ERPs. The systems one can create with such composable architecture are pre-packaged, and will always lead to a given set of applications that will just differ one from the others by which modules are includes + given number of specifically added fields. But we don’t go out of the box.

That’s good ! And the right solution for a full range of applications.

What I envision though, and is for a different target than composable architectures, is a fully flexible solution where end users can actually imagine and create applications from scratch, with almost no limit, thus leaving it to infinite possibilities of what can be created. And this is done through a fully model-driven, low-code approach, with a right level of collaboration between tech guys (who initiate app metamodels and generation templates) and end users, who instantiate meta-models for creating full fledge applications.

The reason I think this is important is because we need to allow for a fully open system where end users can fully express their creativity so that they can create something completely new that does not look like anything we know. Because most of what we know is created by the old, and with an energy of competition and profit. We need to get out of the box and bring collaborative work and the intelligence of the collective to birth the new, detaching from the conditioning of the old and what we know. And that can not be done through composable pre-made modules that are at the image of what we know today. I believe we can invent platforms and service that serve us and humanity in a way we cannot fathom today, but we need for that to create from blank page and provide tools to accelerate the creation of those new applications so that can try, fail and succeed as much and as fast as we can to converge to what will really serve us in a new way.