Yiannis Psaras

Thanks for the feedback @whizzzkid! SEO is not a goal here. > If we only want to track performance related to interactions with IPFS, then interactions with the page should...

I guess this issue has been addressed. @Jorropo do you need this on a more permanent basis? If so, we should find a place to be reporting these

> Concerning (3), IMO it isn't our problem, if a user decides to rotate its PeerID (assuming it does), the user cannot expect the Content it provides to be reachable....

I really doubt we have anything along those lines in the docs. But I would guess that if someone has the technical knowledge to change the node's ID, they would...

Thanks for the input @mxinden! > ... over time I guess here you mean that it would favour the fastest user at the Bitswap level, right? I.e., if it establishes...

After a brief discussion with @dennis-tra he brought up the idea of the honeypot deployed for the NAT Hole Punching study being able to help with this. Indeed, the honeypot...

Interesting! Thanks for digging in. So, good news and bad news: - Good: we have the infra set up to measure this pretty much directly. - Bad: we don't have...

Just to add that the thinking here is to extrapolate from the portion of the key space that the honeypot is covering to the entire network. Of course, this assumes...

There are many other sites that I see we've got problems with: - https://probelab.io/websites/docs.libp2p.io/#website-trend-hosters - https://probelab.io/websites/filecoin.io/#website-trend-hosters - https://probelab.io/websites/green.filecoin.io/#website-trend-hosters - https://probelab.io/websites/ipfs.tech/#website-trend-hosters - https://probelab.io/websites/libp2p.io/#website-trend-hosters - https://probelab.io/websites/protocol.ai/#website-trend-hosters - https://probelab.io/websites/research.protocol.ai/#website-trend-hosters - https://probelab.io/websites/specs.ipfs.tech/#website-trend-hosters - https://probelab.io/websites/web3.storage/#website-trend-hosters...

One thing I'm thinking we could try out is reducing the reprovide interval, which is currently set to 22hrs. We've changed this according to our study (https://github.com/protocol/network-measurements/blob/master/results/rfm17-provider-record-liveness.md#44-State-of-PR-Holders-over-time), but I'm wondering...