This milestone serves the purpose of setting the methodology plan for the rest of the project. The milestone includes reviewing of the suggested methodology and the code that needs to be implemented in order to get the right results. This is the right time to make amendments to the suggested methodology. The methodology plan should also identify and flag any potential blockers, or difficulties faced when applying the methodology.

Methodology details

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. The initial results cover requests both from IPFS Gateways and go-ipfs clients through Bitswap.

Initial Results / Proof of Concept

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

Knowing whether there is locality of interest in the IPFS network can help a lot when making several protocol design decisions. For instance, several people in the community have experimented with multi-level DHTs (ML-DHTs). These would only make sense if there is some correlation between the requested content and the location of the clients requesting content. Based on data from public IPFS gateways, we want to get the location of IPFS users and the requested content. This would allow us to measure the locality of CIDs in relation to the users that issue requests. It would also allow us to understand at which locations are nodes actually involved in serving content.

We would like to see if there is any correlation between the location of end-users/clients and the content they request (e.g., content from the same geographic region). This information can help shape content routing algorithms and the DHT.

Location of IPFS end users and requested content

Active workers:

Jump to section:

Location of IPFS end users and requested content

Problem Description

Solution Requirements

Milestones

Other Information