Developer can use another developer's canister

[ghost]

[hansl]

I think there are 2 3 parts to this issue/design;

1. a short term part where we just allow people to specify a map of names to canister ID (and optionally which candid interface), so they can use it in their canisters, frontends or dfx canister call as named canisters,
2. ADDED: a middle term part where a mock can be built around the candid file interface,
3. a longer term part where we can install locally canisters that we don't have the source code for.

The second third part is way harder than the first ones to design, as it requires mechanics from the replica that we do not have. For an incremental value to the developers I would suggest sticking this specific issue to the first part (which would provide a lot of value already), and leave the second last parts for other issues and stories later.

The idea would be that, in dfx.json, a new canister type (and builder) would be added which contains a map of network => canister ID, and an optional (or mandatory) DID file. The build step would skip building, the deploy would skip deploying, but everything else in dfx would remain mostly unchanged.

EDIT: Added a third middle step after @chenyan-dfinity's suggestion

[chenyan-dfinity]

I agree. There can be a mid-term part where we mock the response based on the did file, so that developers can make some progress in the local replica without accessing to external network and paying for cycles.

[hansl]

Sorry, I thought you meant that the first one would be the mock, but I see there is 3 tiers here; error out if there's no canister, build/install a mock canister, and 3 actually build the canister.

There's even a 4th thing we could do; inter network calls to the real IC from a local one, so you're talking to the IC's real canister using a local canister proxy. This could be made as a feature of the emulator.

[nomeata]

Maybe a step 1½ where the developer just specifies the canister id, and dfx tries to obtain the interface description from the network.

There's even a 4th thing we could do; inter network calls to the real IC from a local one, so you're talking to the IC's real canister using a local canister proxy. This could be made as a feature of the emulator.

Interesting! Wouldn't work quite seamless (i.e. the sender wouldn’t be a canister id, but necessarily a user id or the anonymous user; can’t send cycles…), but for some cases it might work.

[chenyan-dfinity]

dfx tries to obtain the interface description from the network.

Can we put this in the public spec?

[hansl]

Candid is not in the public spec, unfortunately. Until that happens there won't be any hope of having any interface definition feature in the public spec.

[chenyan-dfinity]

We can still have getMetadata : (principal) -> (opt blob) to return a blob of meta data.

[hansl]

That's a bad patch that does not scale; there's no mimetype associated with the blob, there's no discovery method (is getMetadata for interfaces or is this canister doing somethign entirely different?) etc.

The closest you'll get to a standard like that is using my proposal here. An exported method will never be part of the spec (and IMO shouldn't be).

[nomeata]

dfx tries to obtain the interface description from the network.

Can we put this in the public spec?

Wrong layer. It should, if anything, be in the Candid spec. Until we have resolved this, I suggest to just use the existing __get_candid_interface_tmp_hack method to at least play with these features. Our developers don’t care too much about how this works internally, but they do care about that it works.

[crusso]

Candid is kind of in the public spec though, in the sense that the interface of the management canister is specified with Candid. Thin end of the wedge?

[crusso]

Isn't there another option though?

Instead of hardcoding a canister reference in the client, which will almost certainly be unavailable or different when mocked on the local replica, write the client as an actor class (parameterize Candid service) and instantiate it locally with the mock canister, if desired, and remotely in production with the real canister id of the running service. Is that too awkward? It means we could compile the code once and use it both in testing and production by supplying a different local or remote canister id on installation.

[chenyan-dfinity]

write the client as an actor class (parameterize Candid service) and instantiate it locally with the mock canister, if desired, and remotely in production with the real canister id of the running service.

IIRC, you are suggesting a proxy canister class that behaves differently on different network? That seems interesting to me.

[hansl]

These are way more complex than the first step I'm suggesting; a simple string => canisterId + optional DID mapping to use with DFX. Let's keep it there and design THIS, then we can move to future milestones.

the interface of the management canister is specified with Candid

I forgot about that. I guess that's a bonus argument to add system support for Candid as it already needs to be supported by everyone using management canister (ie. basically everyone).

[crusso]

Actually, I was suggesting something that is (I believe) expressible in dfx today.

Write your client as an actor class in motoko, taking the dependency as an actor class parameter.

Deploy it locally passing, the id of the mock dependency as the argument.

Deploy it on the network, passing the id of the real canister as the argument.

This assumes that dfx can pass arguments at canister installation, local or remote, but I think that's been true for a while now.

It does mean you have to specify the type of the dependency on your actor class parameter.

For example:

type BigMap = actor {
  find : Nat -> async Blob
};

actor class CanCan(bigMap:BigMap) {
   //... bigMap.find(hash(...)) ...
};