Review Philip's ideas and work about app composition

[lucksus]

As a member of the team, I want to understand the work on composition that philip has done. child of #6

[thedavidmeister]

here is my take on two of the core ideas that came up in our discussion yesterday

zome references/manager

This is the npm equivalent for zomes (zpm).

As a developer, I want to be able to:

• Reference common universal zomes from a DNA file by some universal ID (e.g. hash, url, uuid) that are not currently present in the app directory
• Some build tool downloads/copies/symlinks referenced zomes somewhere
• There is an integrity check done for downloaded/referenced zomes (e.g. hash) so that they are enforced as "read only" or "known good" for app developers
• Many apps can reference any shared zome
• Shared zomes may provide their own analogy to dna.json, e.g. zome.json, that may implement that zome's config currently implemented under "Zomes" in dna.json

So that I can:

• have a high degree of confidence in the integrity of low level "lego block" zomes during deployment/distribution/migrations
• avoid human error when maintaining common zomes over time
• reduce manual labour during development
• review pinned versions of common zomes "at a glance" from the dna.json file

multi-app HC

As a developer I want to be able to:

• Run a single hc instance (e.g. hcdev web) in any working directory
• Send dna.json data to the hc instance along with the zome/fn/params data we already send now
• Zomes required by sent dna.json data will be looked up in the current working directory first, then by reference as per "zpm" described above

So that I can:

• Easily run many versions of an app in parallel (e.g. chat room use case, or helping maintain the health of the DHT from old versions of an app)
• Allow the client/ui to define the DNA used to build apps in an ad-hoc manner
• Reduce manual labour/ops associated with running hcdev across many tabs/ports
• Simplify development for UIs that rely on several backing apps
• Create invite links "on the fly" for short lived apps (e.g. chat room use case)

[thedavidmeister]

There is a super lo-fi symlink based proof of concept for zpm in https://github.com/thedavidmeister/holochain-examples-migrate/tree/master/apps/1.1/dna showing a single zome linked into two different apps from outside both apps.

[gavinrogers]

We might be able to accomplish this using nix, and I'm going to just demonstrate that we can support osx, linux and Windows developers (and users) with a basic POC.

[thedavidmeister]

@gavinrogers by "this" we mean:

• reimplement the symlinked migrateZome example through some scriptable process/tool
• migrateZome must be accessible from one external source, e.g. github, nix channel, etc.
• must be clear how the tool achieves the basic zpm requirements for zome integrity and sharing outlined above ^^
• must be clear from the POC how additional zome sources can be added in the future
• the tool only has to be dApp developer facing at this stage
• ensure the tool works on the main 3 OS that devs use to build things
• a basic step by step tutorial can be produced and published for each OS, allowing devs to easily reproduce the implementation on their own systems
  • e.g. https://medium.com/holochain/holochain-progress-update-migrations-80ef5290fb67
• there is NOT any requirement to change/integrate the way that DNA/HC natively works at this stage
  • adding additional package management config to the app alongside dna.json (e.g. nix derivation, package.json) is OK
  • zome.js and multi-app HC is totally out of scope for this POC

[thedavidmeister]

@lucksus @philipbeadle @zippy ^^ FYI

[samrose]

One (possible) longterm consideration is how people in general will get this onto their machines in a simple way.

One idea is that we could produce binaries (similar to what hashicorp does for Vagrant, Terraform, etc) that bootstrap, configure and install what is needed. From there we can also decide if we want to expose nix to the end user, or create some DSL or configuration that compiles to nix, etc.

These are just some considerations from the perspective of the wider audience who may not be familiar with systems like nix for instance. If you have questions about what I've written above ("why would we want to do x, when we can do y?" etc) your answer to your own question may be as good as mine! :)

Mostly I am trying to offer thinking here about how people in the wild will contend with this. We could go the route of educating them/guiding them which is viable, or we could simplify programmatic interfaces (at least 2 options anyway).

[thedavidmeister]

@samrose this is very carefully crafted to avoid those discussions, but that doesn't mean will avoid figuring this out forever ;)

[samrose]

@thedavidmeister fair enough thanks!