Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: return providing peer(s) in bitswap:want-block:block event #586

Open
SgtPooki opened this issue Jul 27, 2023 · 1 comment
Open

feat: return providing peer(s) in bitswap:want-block:block event #586

SgtPooki opened this issue Jul 27, 2023 · 1 comment
Labels
effort/hours Estimated to take one or several hours exp/beginner Can be confidently tackled by newcomers good first issue Good issue for new contributors help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature P2 Medium: Good to have, but can wait until someone steps up status/ready Ready to be worked

Comments

@SgtPooki
Copy link
Member

Question

Using Helia, when I download the contents of a CID, could I easily see which node I ultimately retrieved the data from? How would I do that?

Answer

This could be added to bitswap - the hasBlock method here would need the id of the providing peer added as an argument, then the bitswap:want-block:block event could hold both the CID of the incoming block and the providing peer when it's emitted here.

It's worth noting that if the DAG referenced by a CID is made from multiple blocks, these blocks could come from different peers, so it'd be more like "which node(s)" rather than "which node".

This question came across in ip-js channel on slack: https://filecoinproject.slack.com/archives/C046HDAHA13/p1689877647075909

@SgtPooki SgtPooki added the need/triage Needs initial labeling and prioritization label Jul 27, 2023
@welcome
Copy link

welcome bot commented Jul 27, 2023

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

  • "Priority" labels will show how urgent this is for the team.
  • "Status" labels will show if this is ready to be worked on, blocked, or in progress.
  • "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

@SgtPooki SgtPooki added help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature status/ready Ready to be worked P2 Medium: Good to have, but can wait until someone steps up good first issue Good issue for new contributors exp/beginner Can be confidently tackled by newcomers effort/hours Estimated to take one or several hours and removed need/triage Needs initial labeling and prioritization labels Jul 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/hours Estimated to take one or several hours exp/beginner Can be confidently tackled by newcomers good first issue Good issue for new contributors help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature P2 Medium: Good to have, but can wait until someone steps up status/ready Ready to be worked
Projects
No open projects
Development

No branches or pull requests

1 participant