feat: types for sync_state_genSyncSpec

[harrysolovay]

• Some additional types
• An additional binding in effects/rpc_known_methods.ts

[tjjfvi]

The main thing blocking this is figuring out how to incorporate the chain spec into the url. I'd suggest we use //s as separators, but deno's LS currently breaks on this – we should open an issue.

[harrysolovay]

figuring out how to incorporate the chain spec into the url

Good question: I was thinking something along the lines of...

https://capi.dev/smoldot/ipfs:{hash}/mod.ts

in this example, the {hash} is an IPFS CID, pointing to a chain spec.

I suppose this doesn't take into account the full life cycle

1. get a quick reference during development
2. bundle/ship an app, with the chain spec (?)
3. app instances must somehow maintain versions of the chain spec / keep it up to date
4. ...

Thoughts @wirednkod?

[wirednkod]

Let me try to give my 2 cents here - which is based on some assumptions:

• There is an API on substrate (or potentially could be created) that can generate the specs on the spot with the latest state in it;
• There will still be 4 "known-specs" (Polkadot, Kusama, Westend, Rococo);

Having said that I think that there could be 2 possible solutions:
a) CAPI will expose an api for each app to receive/generate the latest chainspec as needed "on-the-spot"; This way the app owner is responsible for calling that api in order to get the latest specs (and bootnodes?) for the well known chain (or even better CAPI internally could call that API when a known-spec is used);
b) an internal parity worker is generating and saving chainspecs on an IPFS and a CAPI api is retrieving latest chainspecs from that IPFS (there could also be have a domain name link to that IPFS etc).

TBH I do not think that chainspecs should be "saved" somewhere in a URL/IPFS or anything if there is a Substrate on-chain API that one can use to retrieve those;
For dev purposes there could maybe exist, the (b) solution above providing "dev specs"

Finally I want to bring to your attention the whole bootnodes thing, as food for thought: ATM SC is shipping for known chains the Parity maintained bootnodes, but this comes with the assumption that devs trust Parity endpoints. With latest release of SC extension it provides the option for a user to alter those bootnodes based on his preference. I think that altering bootnodes should be possible for dApp devs to provide or add their own bootnodes if interested into doing that;

[tjjfvi]

I think we should separate the discovery value used for the codegen from the discovery value used at runtime. Right now they're linked, but theoretically it shouldn't matter if, say, a proxy server is used for the codegen but then smoldot is used at runtime, as the codegen only cares about the metadata, as AFAIK that is independent of the way you connect to the chain.

I think it's much more important to support using smoldot at runtime by divorcing the codegen discovery value from the runtime discovery value than by supporting smoldot for the codegen discovery value (although that will, of course, be important). Right now, I don't think there's a great way to do this, but I think this will be feasible upon the integration of env into Rune.

In terms of supporting smoldot for the codegen discovery value: As those who have concern about using proxy servers would likely have similar concerns about using capi.dev, we could, if useful, only support smoldot codegen on the local server, which would allow us to, say, rely on some config passed in via command line to specify the chain spec. For example, the url could just be something like /smoldot/polkadot, and the server could have config mapping polkadot to an appropriately up-to-date chain spec. This way, the URLs are stable, and don't have to change as the chain spec evolves. (Although, given the stability & caching of the codegen, I suspect that the chain spec would not need to be updated all that often for the codegen, though I may be mistaken.)

This would mean:

• people using capi.dev would use a proxy server for the codegen (which, I'll note, greatly aids the readability of the URLs), but would be free to (and, no doubt, encouraged to) use smoldot at runtime
• those running their own server would have the additional option of using smoldot for the codegen, albeit at the price of some extra configuration
  • if we wanted to ease this transition, we could additionally support in the config mapping an alias like polkadot to either to a proxy endpoint or a chain spec, so that people could easily switch at any time

[harrysolovay]

I think it's much more important to support using smoldot at runtime by divorcing the codegen discovery value from the runtime discovery value than by supporting smoldot for the codegen discovery value

I completely agree –– I believe this merits a dedicated issue. @tjjfvi, would you like to copy the body of your latest comment into a new issue?

Meanwhile, I've renamed this PR to reflect a more minor change (not touching on codegen).