These results and the initial development help in order to judge whether we’re on the right track, or if adjustments need to be made. The purpose of this milestone is to identify whether we have enough detail, or if more detail needs to be integrated in the system, whether we will be able to extract the information we need by the final software and results, or if any readjustment needs to be done to the strategy followed.

Initial Results / Proof of Concept

<h3>Reproducible Experiments:</h3>Anyone should be able to reproduce the experiments done by the team. This is especially important for this project, as the dynamics and structure of the IPFS network changes over time and hence, engineering teams, or community members should be able to re-run the experiments in the future. <ol><li>Any code developed for this project should be migrated, or at least linked from the main GH repository: <a href="https://github.com/protocol/network-measurements." rel="noopener noreferrer" target="_blank">https://github.com/protocol/network-measurements.</a></li><li>The code should include detailed documentation/instructions on how to use the developed software, as well as contact details of the team.</li></ol> This milestone is expected before the end of the project and is not expected to be the final software. Updates can be done to the software and documentation after this milestone too. The milestone is needed in order for our team to carefully review the code, the code comments, as well as the HOWTO guide and provide feedback/ask for revisions in case things are not clear.

Reproducible Experiments & Stable Results

We expect a final report that details the main findings which address the Request for Measurements (RFM), the methodology used,&nbsp;as well as any conclusions made and open issues for future investigation. The report is not expected to be long - think of a relatively detailed blogpost. The Final Report should be posted on the GH repository in the designated folder.

Final Report & Weekly Result Reports

This project seeks to identify the participation and contribution of DHT server peers in the Public IPFS Network through a tool that crawls and then continuously monitors the network. We want to learn:<ul><li>Average session length: overall and per agent version.</li><li>Average uptime per day and month (and eventually per year): overall and per session.</li><li>Average interarrival time.</li><li>Geographic distribution of IPFS nodes in the network</li></ul>

This project seeks to identify the participation and contribution of DHT server peers in the Public IPFS Network through a tool that crawls and then continuously monitors the network.

Please login to apply for this grant!