Package usage stats self-reporting system

An important feature of centralized package repositories is that they are capable of reporting statistics which help the authors as well as the community to understand how popular a particular package is.

For example, here are the stats displayed on [npmjs.com for lodash](https://www.npmjs.com/package/lodash):

Developers can use the popularity metrics as a signal for decision making when they need to evaluate which package they should choose for their project.

With peer-to-peer distribution, it is no longer possible to collect download statistics.

This "mini project" proposes that we build an experimental self-reporting system so that consumers of packages can "self-report" package usage metrics back to the authors and community.

Self-reported metrics are necessarily an "honour system" and be prone to faked statistics and manipulation.

To counteract this, this mini project would expect all submitted statistics to be cryptographically signed and tied to a real world public identity, with no expectations of privacy (with BIG WARNINGS!!!). It would be "opt-in".

For the initial proof of concept, we could simplify the implementation by limiting participants to GitHub users, and require participants to verify their identity and register their public keys. A future version might use a more open identity framework, such as [Decentralized IDs](https://w3c-ccg.github.io/did-spec/).

Ideally, participants would be able to generate usage metrics even if they are working offline. Using a 'counter' CRDT (for example, from [js-delta-crdts](https://github.com/ipfs-shipyard/js-delta-crdts#counters)) would let users combine their counts from multiple machines or environments. Metrics could be timestamped so that usage over time could be reported. Participants could choose to review metrics for accuracy before submitting them, or revise their metrics in an 'eventually consistent' manner.

Self-reported statistics could go far beyond simple 'download' counts. Metrics could differentiate between packages used for development vs. production. Self-reported metrics could be multiplied by other metrics such as internet traffic to generate derived metrics.

Bad actors would be able to submit faked metrics, and there is also the possibility of Sybil attacks. The system used for aggregating should be able to subtract the metrics submitted by bad actors. With a CRDT-based approach to aggregation, it might be possible to segregate "more trusted" metrics from "less trusted" sources, and reduce the cost of recalculation. Machine learning techniques could be used to identify suspect metrics.