hydra-api package with lightweight dependencies

[yveshauser]

Why

Developing a Marlowe application running on a Hydra head, we encounter the problem of dependency resolution. marlowe-cardano as well as hydra-poc both define dependencies in cabal.project files. Setting up a new project we have to manually merge the files and pick matching revisions of libraries and their transitive dependencies.

What

The idea is to introduce a new package hydra-api containing the types, that are exposed by the Hydra Client API with only lightweight dependencies, probably just to

• hydra-prelude
• hydra-cardano-api

Like this, the package would introduce a dependency to cardano-api together with the transitive dependencies.

[ch1bo]

I think we should even avoid hydra-prelude.

Can we try to enumerate the types needed? Maybe at first only the entry points, the things you actually want/need in the client and then we will need to figure out how / whether we also need to move the more intracate stuff like UTxOType tx (supporting multiple ledgers / tx formats).

Entrypoint types:

• ServerOutput
• ClientInput
• ...?

[yveshauser]

Yes, it's essentially ClientInput and ServerOutput

[ch1bo]

Okay. So starting from these "roots", let's give a quick overview of types imported there:

• for ClientInput:

import Hydra.ContestationPeriod (ContestationPeriod)
-- ^ The data type should be straight forward to have, but the conversion to the on-chain variant is annoying, as it's coming from `hydra-plutus`

import Hydra.Ledger (IsTx, UTxOType)
-- ^ IsTx is only used for its super-class constraints, most likely the `ToJSON` ones
-- ^ UTxOType is required and will pull in the whole IsTx class. Not an issue though, as I think the `Hydra.Ledger` module is really an interface

• for ServerOutput:

import Hydra.Chain (PostChainTx, PostTxError)
-- ^ PostChainTx is pretty similar in what types it contains, many overlaps with the imports below.
import Hydra.ClientInput (ClientInput (..))
-- ^ See above
import qualified Hydra.Crypto as Hydra
-- ^ These is here because Hydra.MultiSignature, makes sense to put that into an api package.
import Hydra.Ledger (IsTx, UTxOType, ValidationError)
-- ^ See above, plus ValidationError being errors returned by the L2 ledger -> fits an api package.
import Hydra.Network (Host)
-- ^ Small type describing a hostname + port, trivial.
import Hydra.Party (Party)
-- ^ A wrapper around Hydra.VerificationKey (see above), the chain conversion part is problematic like ContestationPeriod
import Hydra.Snapshot (Snapshot, SnapshotNumber)
-- ^ A central concept of the protocol and basically consists of a UTxO set and a snapshot number.
-- The data type itself is no problem, but it's SignableRepresentation requires `plutus`
-- because it is based on plutus' representation of `TxOut`.

In summary I see at least these things to consider:

• Do not move to/from chain conversion functions of ContestationPeriod and Party. Those would need to remain in hydra-node, tying together hydra-plutus and the (future) hydra-api
• Either
  1. split the instance SignableRepresentation Snapshot from Snapshot to not depend on plutus, or,
  2. not use Snapshot in the API, but only it's constituents UTxOType, SnapshotNumber and [tx], or
  3. introduce a SignedSnapshot and use that in the API instead (best option here IMO)

[ch1bo]

Bump

[uhbif19]

Is this planned to be implemented? If yes, can this be added as issue, please.

[ch1bo]

No commitment from the core contributors yet, but I'll bring it to the attention of everyone as the highest voted idea currently and we'll eventually put it on the roadmap.

[uhbif19]

containing the types, that are exposed by the Hydra Client API with only lightweight dependencies

What is Hydra Client API?

[ch1bo]

With this we mostly meant the ClientInput and ServerOutput message types. What we could add to this are functions to do the actual close command over the websocket connection for example.. building this more and more to an SDK?

[uhbif19]

@ch1bo

Seems like there are modules not in Hydra.API.* , but also required for API.

Like Hydra.Chain (HeadId).

[uhbif19]

Imports currently used by hydra-auction, apart from Hydra.Cardano.Api:

import Hydra.Network (Host (..))
import Hydra.Chain (HeadId (..), PostChainTx (..), PostTxError (..))
import Hydra.Snapshot (Snapshot (..))
import Hydra.Chain.Direct.Tx (headIdToCurrencySymbol)
import Hydra.Cluster.Faucet (Marked (..), publishHydraScriptsAs)
import Hydra.API.ClientInput (ClientInput (..))
import Hydra.API.ServerOutput (ServerOutput (..))
import Hydra.Ledger.Cardano (addReferenceInputs)
import Hydra.Ledger.Cardano.Builder (
import Hydra.Contract.Head (hasPT)
import Hydra.Chain.Direct.Util (isMarkedOutput, markerDatumHash)
import Hydra.Crypto (AsType (AsHydraKey), HydraKey)
import Hydra.Party (Party, deriveParty)
import Hydra.Chain.Direct.TimeHandle (mkTimeHandle, slotFromUTCTime)

[uhbif19]

Another issue to consider is orphan instances:

9a27d93