Yiannis Psaras

Copying discussion from slack. From @Stebalien The largest issue here is that libp2p won't try the DHT if it already _thinks_ it knows a peer's addresses. This is a long...

Thanks folks for continuing the discussion here! Replying to a couple of notes: @marten-seemann > One could design logic (and a whole new API) to feed in new addresses from...

> if we request after 30 minutes, we don't get any addresses from our initial DHT query, right? That's what we want to change: the peers that hold provider records...

Good points brought up! I do think that trying the existing multiaddresses first makes sense, but for how long is still to be figured out. A straightforward setting is the...

Thanks for starting this @terichadbourne. I'm finally coming to this, as we're finalising the content that will go to the webpage and we will be launching the project next week....

@terichadbourne the ResNetLab on Tour - On Demand version is live: https://research.protocol.ai/tutorials/resnetlab-on-tour/ I've linked to the great ProtoSchool Tutorials! Please feel free to share with the community! We'd love feedback...

@mishmosh I don't know if this happened, but in any case, could we include ResNetLab on Tour in the next ProtoSchool newsletter? Even if it's duplicate it's fine - we...

I've also created this PR: https://github.com/ProtoSchool/protoschool.github.io/pull/767 to link ResNetLab on Tour from the ProtoSchool page.

Great idea! But will we need Solidity support from within the tutorial to validate the answer? I don't think the current protoschool infra can support such functionality (and would probably...

> Nodes should only "ascend" if they prove that they are willing and committed to provide a good service. This points to a score function for nodes, which is constantly...