Don't get participants from Coordinator with transcripts

[derekpierre]

Use updated getParticipants(ritual_id, startIndex, maxResults, transcripts) contract call to obtain participants for a ritual. Transcripts (the flag to obtain transcripts or not) should be False for just decryption, although in the future if doing local verification you may want it to be True. Note that if transcripts is ever True, eg. for local verification, you will NEED to do pagination. If transcripts are False, then you done "need" pagination.

This functionality is available on lynx but not yet mainnet - it will require a mainnet contract upgrade of the Coordinator.

[piotr-roslaniec]

@derekpierre Any change in contracts API will cause a break in the build in taco-web (as soon as we bump the @nucypher/nucypher-contracts version in taco-web). This is because we are generating typings from contracts automatically, and if something changes between our code and the generated code the TS compiler will pick it up.

This is just to explain that we can detect these sorts of issues and that I will release a new @nucypher/nucypher-contracts version.

[derekpierre]

This is because we are generating typings from contracts automatically, and if something changes between our code and the generated code the TS compiler will pick it up.

Interesting. Does this happen even if the ABI is backwards compatible? Or is it that this doesn't matter - the compiler will still complain? Basically, we only added new methods and did not change the original method being used - that's still available. Technically taco-web is still able to use the original method and can call it in the same way - it's just that we want it to use the new shiny more optimized method instead.

[piotr-roslaniec]

If the ABI doesn't change, there is no way to detect a breaking change in the contract API. But I could argue that if the behavior of (for example) a contract method myMethod changes dramatically without a "visible API change" then it should be at least renamed to myMethodv2 to communicate said change in the behavior to the caller.

Technically taco-web is still able to use the original method and can call it in the same way - it's just that we want it to use the new shiny more optimized method instead.

I see, so it's a non-breaking change but an upgrade nonetheless. So without doing anything, the new @nucypher/nucypher-contracts version will not break the taco-web build, and the taco-web itself will function correctly. Still, we should update it sooner than later.

[derekpierre]

I see, so it's a non-breaking change but an upgrade nonetheless. So without doing anything, the new @nucypher/nucypher-contracts version will not break the taco-web build and the taco-web itself will correctly function.

Exactly - you got it; the issue is efficiency. The same original functionality applies for the old method - it's just that it should not be used. By default, it got participants with transcripts (large amounts of data returned) and that still holds, but really you don't need transcripts so you can get participants without transcripts via an updated call to a new method.