This is a suggestion for @wang’s amazing https://ic.rocks/:
https://ic.rocks/principal/rdmx6-jaaaa-aaaaa-aaadq-cai already shows the “module hash”. Can we take this a step further and link to the source that’s running there? Maybe with a nice visual distinction between “assumed source” and “verified source”?
Verifying the that a certain commit is indeed the source for a canister is a rather manual process, and different for different canisters (see my post Verifying the code of the Internet Identity service (a walk-through)), but maybe we can collaborate somehow on collecting this data, verified by people outside of DFINITY?
Such checkmark (or rather, the lack of it) would also incentivize more canister developers (including the NNS developers…) to share the necessary information to make the code verifyable.
We’ve put this in Canlista actually (soon ™️), collaborating on collecting this data would be great; your post the other day got me thinking on this. Ideas on how to facilitate this would be an interesting discussion—a welcome one!
Canlista works as well, of course, I didn’t want to favor one project over the other here!
Oh not at all! Just interested in the solutions to this… Norton and I were having a chat about it too.
Here’s an idea for someone to build:
A decentralized network of code verifiers
- Verifiers are running docker environments (ec2 or own hardware)
- A project wants to get verified and submits their code, perhaps attached with some tokens as incentive
- Verifiers independently download and compile code
- They submit results and the code is considered verified if a simple majority agree
- Verifiers are rewarded tokens
Perhaps this network can be small and trust-based, eg. 3 reputable community members. Having a large open network will of course require mechanisms to prevent bad actors.
Yup, that’s what I had in mind, although to start simpler, the verification process could initially be manual and done by trustworthy community members. I.e. start with a prominent display of that data, and let the rest follow
Here is another idea. A script that gathers all the mo libraries and merges everything into one mo file. A single file now can be easily compiled with the existing system Motoko playground uses, so no need for a whole docker environment.