zome re-structure mirco-service architecture

[nphias]

currently there is only one zome for the functionality of four distinct parts which could be split into four zomes:

• username attestaion
• wallet attestation
• external_id attestation
• recipes

this would make documentation clearer

[8e8b2c]

I think actually we'll need them all in one zome in order to enable validation that ties everything together. The direction I'm taking this project is one in which you can specify some verifiable aggregation of the various resources in a customisable manor. For example, I imagine might do something like this for producing verifiable winnings-coupon contexts for signing:

{
  '$args': ['recipient_evm_address'],
  match_ids: { doc: 'championships/123/match_ids_final' },
  matches: { doc_list: '$match_ids' },
  player_win_counts: { in: '$matches', jq: '# matches into player_id: win_count' },
  player_ids: { in: '$player_win_counts', jq: '# key of ^' },
  external_ids: { fetch_external_id_attestations: '$player_ids' }
  split: { in: ['$player_win_counts', '$external_ids'], jq: '# filter by external id and calc percentage' },
  caller: { get_pubkey },
  '$return': { in: ['$caller', '$split', '$recipient_evm_address'], jq: '# select percentage and arrange context array' }
}

[8e8b2c]

Rather than splitting everything into zomes, it might still be useful to split them into crates. That would allow other projects to more conveniently include functionality in a partial manor.

[nphias]

Rather than splitting everything into zomes, it might still be useful to split them into crates. That would allow other projects to more conveniently include functionality in a partial manor.

I would say in general zomes are at the crate level of granularity and have their own cargo file.. right now you have four independent features bundled under one zome called username_registry.. Its fine for a repo to maintain multiple zomes which can be later pulled in as independent crates to other projects.

[8e8b2c]

Its fine for a repo to maintain multiple zomes which can be later pulled in as independent crates to other projects.

Could you give me an example of how this would work? I was under the impression (perhaps mistakenly?) that when calling must_get_valid_record in an integrity zome, it is only able to retrieve data for entries defined within that zome.

Let's say I want to validate a Recipe that incorporates an ExternalIdAttestation and an OracleDocument. Can the recipe validation call must_get_valid_record to get the contents of the specified ExternalIdAttestation and OracleDocument for use in the recipe's execution?

[8e8b2c]

@nphias, see validate_create_recipe_execution in https://github.com/holochain-open-dev/holoom/pull/24 for a concrete example of why I want validation across the various entry types.

[dcatki]

Deprioritised

[8e8b2c]

Spike for establishing pattern to make features modular: https://github.com/holochain-open-dev/holoom/pull/98