Simple multi-sig #287
Description
Aside from Gnosis safes, we need to support a lightweight multi-sig system natively. In Valist v1, this was built into the smart contracts. For security and maintenance purposes, this was split off and multi-sig is now an outside factor of the contract.
However, since our releases are a linked list on-chain, and access control is also on-chain, we can perform client-side checks to configure multi-sig rules. This is a similar system to Ceramic, ION, and other DID + anchor based systems.
This will be at the Project-level. Account-level admins should continue using Safes for multi-sig.
An example flow:
- Key generated for CI/CD environment
- Address for this key is added to project member list
- Multi-sig configuration is set for the project, containing the addresses and threshold
- Valist clients check each release for the multi-sig configuration and mark whether or not it's valid
This makes the release tag unreliable for telling which version is actually live/production. This means we'll need to make the tag part of the metadata, and include this in the checks. Related to #285. Tags will become timestamp-based and continuous.
The logic will also be similar to Vercel and Netlify, in that each build has its own identifier and there can be logs of failed builds, but the builds that are promoted to specific environments are what the client sees.