contracts/opl: Host requires Encave address, Enclave requires Host address? about sapphire-paratime

[CedarMist]

One suggestion would just be to let the remote address & chainID to be set whenever the contract wants, so just making them internal rather than private, giving a bit of extra flexibility and options versus the strict 1:1 paired constructors.

[nhynes]

recommend using the Celer IM SDK

The reason it's not like that is because giving up your primary interaction surface (i.e. API) to a third party is bad for the longevity of your business.

And the reason it's "circular" is to avoid making calls to the expensive home chain. I'm also not aware of any concrete use-cases that require octopus messaging. I'd suggest making a separate or extension library for that before making the common case (additionally?) difficult.

[CedarMist]

I agree that OPL can be very neat when the contracts are deployed 1:1 together, with one endpoint on Sapphire and another on a foreign chain, and we should keep it simple.

That being said, I'm sure people will come up with interesting octopus (1:N or N:1) & graph (N:M) patterns, although these can be made with the current pattern by deploying a factory on each chain, or just one pair of contracts for each chain<->chain connection.