#substrate provide means to instantiate hyperspace runtime with custom parachain and relaychain

[dzmitry-lahoda]

as far as I can see right now hyperspace works only with the test chain. you cannot connect it to any other parachain, nor to relay chain of different versions then rococo.

how to provide our chain client to hyperspace?

currently connecting to our relay or to kusama chain using subxt clients from this repo fail as I can see

[blasrodri]

Action point: We need to generate subxt files for Dali/Picasso
Thanks @dzmitry-lahoda

[dzmitry-lahoda]

ok. @obsessed-cake is on task to generate. that will be done soon. question is how to integrate these? you will be able to get any rs file client via nix or cargo.

[blasrodri]

Yes! we are thinking of having two releases of hyperspace on docker hub. One for our local para chain node runtime, and another for Dali. So we pull those generated files, and build hyperspace with these depending on which runtime we're targeting.
Then on composable repo, we refer to the docker image that's using the Dali generated code. Sounds good?

[dzmitry-lahoda]

Subxt hashes runtime metadata and uses it to validate node it connects. I am worried that with copying generated code you will need to update client many times.

I think if Hyperspace would be library, not binary which will depend on trait Runtime { type ParachainClient : ParachainClient; type RelayRuntime : RelayClient where PC and RR are traits. These traits have default implementation which is generated by simple macro for subxt generated client.
TLDR;
composble binary node will reference and setup hyperspace runtime (using above traits, macro and library). And then composable bridge will run composable in hyperspace mode.

That is we remain in subxt hash based client solution.

[dzmitry-lahoda]

For analogy, neither substrate nor cumulus are blockchains, but they are configurable runtime and host infrastructure for such. So hyper space could be configurable runtime for bridges.

[dzmitry-lahoda]

Likely you would not run same instance of bridge serving all chains at once.

[blasrodri]

I'm not sure. We should be able to decouple hyperspace from our Parachain.
@Wizdave97 any thoughts?

[Wizdave97]

hyperspace-core is already a library
I don't see how a trait can be used to represent the runtime metadata of a parachain,
subxt requires static types to work, there's no way it will even compile if the types are not available.
Releasing separate docker images for different parachain runtime releases is the best solution imo

[dzmitry-lahoda]

Great. May you define the flow and how somebody consuming hyperspace will do releases?

If we do otherwise, I pretty well know how to do it.

With docker not sure.

@blasrodri may you help the Picasso team with this that? Imho no need to do work, so define as separate initiate/rfc how we can integrate Picasso into hyperspace the way proposed so we can share it with people and make quesions/suggestions.

[Wizdave97]

We'll work on the coming up with a flexible flow for that this week.

[blasrodri]

Something that @KaiserKarel has suggested is to create a build of hyperspace directly into the composable repo. I believe this could be a good solution. Perhaps combined with @Wizdave97 work, there might be a flexible solution in which we still leverage most of the existing build pipeline in the composable repo, and target multiple runtimes?
@dzmitry-lahoda happy maybe we can set a call for this?
@obsessed-cake any thoughts?

[dzmitry-lahoda]

'create a build of hyperspace directly into the composable' is?

guessing. it is ci clone repo and replace rs files? or we copy paste code into monorepo? or doing fork? or adding hyperspace as git module?

what should be considered?

i know that doing monorepo and doing runtime traits are both working, proven and easy to automate solutions. git mod is closet to monorepo and direct build.

for something in between, need some hint what is proposal.

[dzmitry-lahoda]

yeah. will setup call.

[blasrodri]

Building hyperspace in the mono repo means:

1. Targeting a specific hyperspace commit from the centauri repo.
2. Building hyperspace using the Dali metadata. Can be done through subxt, potentially with subwasm or even Karel suggested https://github.com/scs/substrate-api-client (although @obsessed-cake is warning it not being actively maintained). I'm aware of the fact that Nix doesn't play well w/ subxt, but there seem to be a possibility if we do sandboxed builds as far as I hear. Open to other suggestions.
3. Publish this new version of hyperspace-dali as a docker image into Dockerhub

[dzmitry-lahoda]

1. targeting and then what? we need replace one client with other.
2. subxt works well in nix . use chopstick or subwasm instead of node. latest version of nix works well with any solution. using string based client is possible, so it still requires centauri repo to provide such ability. i mentioned string based client 3 times already. 2 times in cu and 1 time in centauri gh issue.
3. who will publish? ci of monorepo?

[blasrodri]

Targeting and then (2)
CI on monorepo can publish

[blasrodri]

• targeting and then what? we need replace one client with other.
• subxt works well in nix . use chopstick or subwasm instead of node. latest version of nix works well with any solution. using string based client is possible, so it still requires centauri repo to provide such ability. i mentioned string based client 3 times already. 2 times in cu and 1 time in centauri gh issue.
• who will publish? ci of monorepo?

What does "string based client" mean?

[dzmitry-lahoda]

so for 2. proposal is to copy(whatever way it is done) of hyperspace and patch it with dali client.

[dzmitry-lahoda]

generally i think it can be executed. will setup meeting with Cor and obsesed cake to define work.

[dzmitry-lahoda]

as i get it. issue can be closed without modification of centauri?

[blasrodri]

Created a task in CU to track these efforts. Will close this one
https://app.clickup.com/t/865bbdfeu