Rate IPFS content

The application intends to measure the extent an IPFS content is distributed. Less rating for a lone node hosted by you, more rating for few nodes around the globe along with few pinning services.

Comment

Inspiration

In the initial days on web2, it was not as centralized as it now. There were amateur bloggers and repositories hosted by universities. Not everything required a signle-sign-on and depended on alogirthms devised by tech giants.

I feel web3 is at a similar position as web2 in 90s. It requires people to be tech-savvy and willing to pay for servers to really work. We have seen a lot of services come up to make it more convenient for the users to host things on IPFS. But we need to make people aware that pinning a resource on a single service doesn't make it P2P exactly. The data is still centralized to the node run by the service. The aim is to promote a sense of what a healthy IPFS content is, among the users.

What it does

It takes a CID as input from the user, and queries the IPFS network for information about it's providers using the dht API. This data is then used to decide if there are enough providers for this content and subsequently assign it a rating.

How we built it

  • The portal is built using React with the help of Create React App as base.
  • js-ipfs is used to run an IPFS node in the browser.
  • The portal is hosted on IPFS itself using Fleek.
  • ENS is used as the domain service to point at the hosted IPFS resource.

Challenges we ran into

1. Issues with Svelte

I initially attempted to build this using Svelte, instead of React as the web framework. but that could not succeed due to what I think, were issues with how the the bundler works in Svelte.

2. Issues with js-ipfs

a. dht.findProviders did not work

js-ipfs does not have a parity in features with go-ipfs, especially when it comes the dht API. When I started building it, I found out multiple issues existed , most importantly #3502 which made it unlikely for this project to be completed but it got resolved a week before the deadline giving this project a chance.

b. dht.findProviders does not return multiaddrs

The project relied on multiaddrs returned from dht.findProviders method to create a geographical distribution of the providers and consider that in the rating, but this method does not return multiaddrs so that plan was abandoned.

3. ENS linking

Linking an ENS domain proved to be tougher than imagined due to the very high gas fees costing $3000 at one point. In time, I was able to get the ENS domain when the gas fees were relatively low.

Accomplishments that we're proud of

  • Finishing the project in-time even given that dht API in js-ipfs is not stable.
  • The logic and structure is simple enough to add other data points like geography of providers, pinning services, etc. to provide ratings.
  • The IPFS node returns providers and other data depending on what and how many peers are connected to it. So before fetching the providers, we fetch the data first in order to get the right peers.

What we learned

  • We learned that an IPFS node requires some time to boot up and build a pool of peer to reliably give information.
  • We learned that the list of providers returned by IPFS may not be exhaustive and it depends on what peers are connected to the node.
  • We learned how to connect IPFS and ENS using Fleek.

What's next for Rate IPFS content

  • Contributing to js-ipfs to resolve issues with dht.findProviders and dht.findPeers methods.
  • Integrating a mapping library to geographically visualize the providers of a content.
  • Nudging users to use pin services using the new Pinning API to improve the ratings.

Built With

Share this project:

Updates