What are zomes vs dna

Technical Discussion Best Practices
#1

What’s the advantage of using multiple zomes over creating multiple dnas? In other words, whats the purpose of zomes.

2 Likes
Technical Holochain 101 - for semi-noobies like me
#2

Zomes (short for chromosomes) are like modules to the DNA (the whole application): they are the domain specific package that knows how to create, retrieve, link, etc. certain kinds of entries.

Multiple zomes can come together to create different DNAs. For example, I could write these different zomes:

  • Roles zome
  • Blogging zome
  • File storage zome
  • Currency zome
  • Calendar zome
  • Reputation zome
  • Communities zome
  • Content management zome
  • Index/filtering zome

And from this list I can group different zomes together to make different happs:

  • Meetup clone:
    • Calendar zome
    • Communities zome
    • Currency zome
    • Roles zome
    • Index/filtering
  • Wikipedia clone:
    • Roles zome
    • Content management zome
    • Index/filtering zome
  • Twitter clone:
    • Index/filtering zome
    • Blogging zome
    • File storage zome

Etcetera. Let me know if you want further clarification.

8 Likes
#3

@guillemcordoba

Why not make all these DNA and bridge them together as needed? Ex: roles dna, blogging dna, file storage dna…etc.

#4

Yes! I see what you were referring to now, you’re looking for the next level explanation :slight_smile:

In a way, a happ instance is defined by its membrane (who is allowed to enter the app). Each happ will have different members, and will create its own DHT. This permissioned space manages agent validation, gossip mechanisms and data availability across all its zomes.

As a consequence, you generally architect and design zomes and happs thinking on who is allowed to enter the happ. For example, when doing a communities app, you may want to pack all its zomes in one dna, and have one instance of that dna (effectively, a new network) for each community.

Going the extreme of having every zome be its own happ ends up replicating a lot of network activity, you lose visibility from one zome to another (you can still bridge, but don’t have direct access to other’s zome entries through the source chain or DHT), and you can end up having weird situations. For example, imagine that we design the communities happ so that every zome is its own happ. If someone tries to cheat by breaking the validation rules in one happ, by default they get kicked out of the network. But in this case they will still have access to all other functionalities of all the other happs of that same community!

So, it really depends on the use-case to define what should be a separate app and what should not. I think there will be a lot of experimentation before settling on best practices.

Let me know if you want further explanation.

10 Likes
#5

@guillemcordoba

Yes! This was the clarification I was looking for :slight_smile:

The point about being partially kicked out of a bundle is a hilarious side effect.

4 Likes
#6

I might be a little late to this, but here’s my two cents Alex. Use multiple zomes for little to medium apps, and different happs for big apps where modularity is key. Communication between zomes is way easier and you can skip bridging just by accessing the DNA that the zomes share.

You can also share data structures between zomes by creating a personal lib folder, defining your data structures in there and accessing them from the zomes via referencing your library via Cargo.toml

The common library idea can be also useful for different happs (with different DNAs) to mantain consistency between happs.

4 Likes
#7

Thanks for this, can you please expand on why you would use multiple hApps for larger apps? Would this not cause more issues as explained above with sharing data, multiple networks, being kicked out, etc? What are pros and cons? Thanks. :slight_smile:

1 Like
#8

Having several happs is all about modularity, having separate happs you can encapsulate different rules and workflows and update/improve the inner workings of each one without having to update the whole system.

You can also create more happs that benefit from the previous ones, like making an happ for user profiles and then making several happs that get the user data from said happ. Perfect for systems that change constantly.

This principle has been used over and over again in computer science, as an example, the interner works in layers, each one providing a service to the layer above it and not worring about the inner workings of the ones below it. That’s why you can make a website without having to worry about whether the final user is using IPV4 or IPV6.

Another example is Oodo, a widely used ERP that hosts several apps and allows the sysadmin to add new ones that use services provided by the previous ones.

1 Like