- Certain user groups (such as scientific research organizations, and binary/library package managers) will not adopt IPFS unless they can track metrics and usage statistics in as good or better ways as they do today. Today, download count is used as a proxy for usage. How could IPFS provide even better metrics/stats?
- How are applications using IPFS features today? How are those applications themselves being used?
By the end of the session, we'd like to have a prioritized list of features that would most help applications built on top of IPFS and an accompanying set of ideas/proposals for how they might be implemented.
We should be able to provide that list to the IPFS development team to help focus their time and energy on highest-value work.
- Collection Logistics
- How to collect telemetry-like application metrics and usage in a distributed world?
- Is metric collection done by a separate kind of IPFS node? If so, who runs these collector nodes?
- Storage Logistics
- Where do the collected metrics go?
- How is the metrics datastore accessed?
- Who can access this metrics datastore?
- Meaningful Statistics
- What information can we reliably extract from the network?
- How to determine the distribution of a file across the network?
- What is the average lifetime of a file on IPFS?
- What statistics become meaningless or impossible to measure in the context of IPFS?
- What is the download count of a file?
- What information can we reliably extract from the network?
- Telemetry collection MUST allow for opting out, ideally though, it should be opt-in
- Metrics should be meaningful, or at least a proxy for something meaningful, and if all else fails, it should be understood where certain metrics fall short in conveying meaning1
- Increased traffic on the IPFS network, a certain amount is acceptable but there is a limit
- ipfs-inactive/package-managers#6
- ipfs/notes#107
- ipfs/ipfs-gui#33
- ipfs/kubo#5912
- ipfs-shipyard/integration-mini-projects#14
- https://github.com/whyrusleeping/ipfs-counter
🎤 Slides
TODO