Having looked into this a bit as part of cardano-scaling/hydra-explorer#5 I think it's worth making some notes:

1. I don't think it's best to invoke hydra-explorer multiple times; let's just make an option for the chain-observer to look for multiple "versions"
2. A version is defined by the Tx Id in networks.json and the script outputs from there; from this a ScriptInfo datatype can be reconstructed
3. This can be used by the chain-observer to send ticks

I.e. the real limitation is with the chain-observer; so we just need to make that parameterisable by a specific ScriptInfo parameter; then maybe we just run multiple chain-observers, or (probably better) run a single one that attempts to find all the ScriptInfo things that it is provided.

-- Edit:

As discussed with @ffakenz and @ch1bo , it is not possible to "de-version" the relevant parts of the chain-observer code (i.e. to parameterise it by the version), because all the version information is essentially hard-coded in the code itself; so it's easier just to depend on different revisions of the code and adapt them to write to a generic (?JSON) format consumable by the hydra-explorer.

We discussed again the intended architecture of this and drew this picture today. It shows multiple versions of the chain observing code (in hydra-chain-observer) and also running on multiple networks / against different cardano-nodes, all aggregating data into a single hydra-explorer instance.

When working on this I realized that a lot of our dependencies could be improved. For example:

• The hydra-explorer now depends on hydra-tx (which depends on hydra-plutus scripts), only for the "interface" types like HeadId, Snapshot etc. Having a hydra-api, that contains Hydra specific entities and (hydra-)cardano-api that contains cardano specific entities would be more suitable.
• Similarly, the hydra-explorer depends on hydra-node mainly because of the OnChainTx type in Hydra.Chain. Either, we deliberately sever that dependency by replicating a compatible type into hydra-explorer, or we could move that (and other chain interface things) into a hydra-chain package. This would be used by all applications, the hydra-chain-observer, hydra-explorer and hydra-node.

I dont think just a hydra-api library could carry the acceptance criteria needed to know that those types are well-defined for the task, i.e it needs hydra-tx to know itself, so I would probably want to keep those types in hydra-tx, and pull the types from there knowing that they are book kept with the contract tests.

I dont think just a hydra-api library could carry the acceptance criteria needed to know that those types are well-defined for the task, i.e it needs hydra-tx to know itself, so I would probably want to keep those types in hydra-tx, and pull the types from there knowing that they are book kept with the contract tests.

@locallycompact What acceptance criteria? I don't understand "i.e it needs hydra-tx to know itself". This is about the explorer, which just wants to use those types when communicating with hydra-chain-observer and offering API to its clients. Which is quite a similar use case than (Haskell) clients to the hydra-node, who just want to understand the API provided to them. Hence, my thought that would be a hydra-api package.

Having a hydra-api package that just contains interface types (Snapshot, HeadId) for use by downstream applications like hydra-explorer is dubious in my opinion because the evidence that those types are sound are the hydra-tx tests. I can't imagine hydra-api alone having any tests (acceptance criteria) that would be any smaller than the hydra-tx contract tests.

Having a hydra-api package that just contains interface types (Snapshot, HeadId) for use by downstream applications like hydra-explorer is dubious in my opinion because the evidence that those types are sound are the hydra-tx tests. I can't imagine hydra-api alone having any tests (acceptance criteria) that would be any smaller than the hydra-tx contract tests.

I see what you mean and respectfully disagree. The types themselves can have semantics that is not necessarily tied to how they are used in L1 hydra protocol transactions (= hydra-tx using them), for example any conversion between them, serialization to binary (currently not tested, but should be), serialization to json, law-fulness of instances etc.

OK. I'm inclined towards more library separation than less. But is hydra-api the correct name for it? It sounds more like hydra-type-definitions maybe?

OK. I'm inclined towards more library separation than less. But is hydra-api the correct name for it? It sounds more like hydra-type-definitions maybe?

@locallycompact see also #432 (comment)