Add an ability to specify a node version in `Cohort`

[piotr-roslaniec]

• User adds a version field to the Cohort object to select a group of nodes that satisfy certain node version
• Porter must expose another query parameter in /get_ursulas: version
• version structure should follow semver, or whichever scheme we use to denote node version

[jMyles]

Is there an archived convo for the reasoning behind this?

Seems like a reasonable enough idea.

What kind of incentive structure exists for updating? Is there a chance we inadvertently incentivize nodes not to update?

[piotr-roslaniec]

I created this issue after sharing the idea on Discord.

The gist of it is that even if node operators are incentivized to update their nodes, there is a possibility that sampling will result in a set of incompatible nodes - There is a period of instability between releases where node operators have to update, etc. My line of thinking is that the policy creator should have finer control over that.

[arjunhassard]

Seems like a trade-off between (1) Slow adopters creating a centre of gravity around older versions (2) Cohorts comprising nodes with different versions breaking things

For maximum uniformity it arguably should be a protocol-driven sampling constraint, rather than a discretionary parameter. I.e. you can only be selected if you've updated to the latest version, unless an adopter goes and changes the client code.

The question then becomes, what about long-standing Cohorts in which some update and some do not?

[jMyles]

For maximum uniformity it arguably should be a protocol-driven sampling constraint, rather than a discretionary parameter.

I'm increasingly finding myself with this view generally, not only for the purposes of this issue.

The question then becomes, what about long-standing Cohorts in which some update and some do not?

Definitely one of the hardcore challenges of long thinking.

[arjunhassard]

This becomes much more of a problem when a given app is creating lots of cohorts on the fly, whereas for early versions they're unlikely to have more than a single semi-perpetual cohort. On the staker side, we can assume a level of professionalism (given the smaller group) and sampling/incentive mitigations to make sure all nodes are on the latest version

[derekpierre]

Will be addressed as part of https://github.com/nucypher/taco-web/issues/264