Idea: paid subscriptions to stdlib distribution developers

[spalladino]

A few weeks ago we were discussing with @AlbertoGozzi potential alternatives for paying out rewards to developers who contribute to an stdlib, besides the fraction of the vouching in the current mechanics.

One option that came out was that Distributions (ie a sequence of releases of a stdlib by a single team) could work by paying "subscriptions" from different projects. This way, a project can only request which is the current "blessed" release version if it has paid its fair share of tokens.

The motivation for paying a subscription to retrieve that information on-chain, instead of simply monitoring it off-chain (as it is publicly available), is that automatic upgradeability strategies could be tied to these subscriptions. So, for a project to have a way of deciding when to upgrade the underlying stdlib, without requiring a centralized decision by the project's devs, it could choose to pay to a team behind a distribution so migrating requires their input (and this requirement is enforced on-chain).

There are some details pending, such as how to prevent a single contract from paying a subscription, and then relaying (trustlessly and for free) this information to any other project that requires it. But I'm leaving the idea here to discuss it after the MVP.

[frangio]

Is the Distribution concept different from the Package concept?

[spalladino]

Distribution would be a Package of stdlibs