A big conversation has opened up around modularisation and splitting functionality into separate DNAs, vs having stuff in different zomes within the same DNA.
Core framing: DNAs are like microservices. Zomes are not like microservices at all, they’re more like libraries. They cannot be remixed without developer know-how.
So there is a big accessibility concern here— non-technical users should be able to create their own arrangements of apps out of existing building blocks, to service their particular needs.
When it comes to groups- ideally I don’t want to have to have a group membership zome in every DNA in an application suite - awkward to synchronise and maintain the code during updates. We also don’t want to end up with “one DNA per app” for the same maintenance reasons, but also to facilitate diversity of features (we want to empower users to swap microservices out for others that are more appropriate to their context). The ideal for me is that groups act like “lobby networks”, and one group agent DNA is the point of authority for several other cooperating DNAs within an application suite - it’s not just one big network, but a collection of networks in a “neighbourhood”.
Potential disadvantages of this degree of granularity were raised (many thanks to @guillemcordoba for his deep insights), to which I have some potential approaches, but there are gaps. These points are discussed in the context of a Reddit-like app (with membership, subreddits and voting modules) to give some tangibility to the discussion-
Membrane inconsistency
ie. one DNA for all of Reddit, vs separate DNAs for every subreddit.
If every subreddit is its own DHT, and someone wants to create a new subreddit but maintaining the membrane with the same people, they basically have to clone the DNA and start the membrane vouching problem all over again. If instead, I can have multiple subreddits in the same DNA, I can just create another one in that same app.
I’m not sure that this is a correct interpretation of the design I’m aiming for. What I would like is for there to be a “delegated authority” zome within each subreddit DNA, and for all those zomes to delegate to the same group membership / registration DNA for access control. So, the membership would be carried across.
The alternative is building non-trivial membership functionality into the monolithic DNA which manages who is in which subreddit.
In order to do this the modular way, each subreddit network needs to be forced to authenticate against the specific group membership DNA (otherwise users can swap in any random group and authenticate against it). There are some thoughts on how to do this, but it’s still an unsolved problem that needs to be discussed separately. Most likely, every zome API method in the subreddit needs to manually check against the membership data on each request. Capabilities do not work for this- they manage user-to-user permissioning, not groupwise permissioning.
Validation rules / warrant inconsistency
Holochain warrants don’t cross DNAs. So, if I hack a separate voting DNA and do something like give myself a heap of upvotes and then get banned, I don’t also get banned from the membership DNA.
Possible ways to address this:
- We have the same validation rules in both DNAs and we bring invalid data from one DNA to the other (we need to trust the agent that is actually doing the bridging, somehow), and holochain develops a custom “emit warrant” function (which I wouldn’t bet on). This doesn’t seem feasible at first glance because it would defeat separation of concerns between the modules.
- We have the validation rules of the voting DNA depend on the membership DNA through bridging (and even then we are not preventing new invalid votes to be cast). This Guillem is very wary of since it includes its own group of requirements problems:
- The voting DNA has a hard dependency on the membership DNA: all nodes that have the voting DNA installed need to also have installed the membership DNA. What happens when we want to update only the membership DNA? What governance should be coded around changing the allowable set of membership DNAs we authenticate against? A curly problem, but not an unsolvable one.
- The voting DNA has to trust the membership DNA to be deterministic on the function calls inside the validation rules. Maybe OK with standard zome traits. Does it really matter though? You can always retry operations after the membership DNA has synchronised.
- We don’t think holochain internals can catch “DHT call determinism”. For example, if in a validation rule there is a
get_entryto the DHT, holochain subconscious will try to retrieve the entry and if there is a timeout and it does not find it, it will pause the validation of the entry and resume it later. This way, we achieve determinism in validation rules while allowing to query the DHT. BUT, if this is done accross DNAs, I don’t think holochain subconscious can do the same tricks, so if there is some error in retrieving the entry in the other DNA, that validation rule will fail and this entry marked invalid (when it was not). Unclear whether this feature will be possible in future.
Access control inconsistency
Imagine that, in trust networks, I only want to share my voting data with the people that are already inside the membrane (my neighbors). I don’t want any other agent to be able to see the data. If voting and content DNAs are separated, how do I achieve that? Possible solutions:
- The voting DNA needs to include the same membrane as the content one. Issue was raised as “have to keep updating both membranes when a new agent is vouched for, for example”, but I don’t think this applies if implemented as delegated authority. The whole point is to have group membership auth in one single location, shared by all DNAs in the neighbourhood.
- Personas way + global shared voting DNA: every agent has its own little “votes DNA”. This will allow any DNA to use the personal DNA for every agent to store their voting information. Disadvantage is, if other agents want to read my votes, I can grant them permissions to do so with capability tokens, through the shared voting DNA and then bridging to my personal DNA. But I pretty much have to keep the capability tokens in sync with the membranes of the shared spaces in which I’m in, which have different rules… Seems hard.
@guillemcordoba please provide any corrections / additions to these comments, I have butchered your original posts quite a bit in this distillation heh
