-
Notifications
You must be signed in to change notification settings - Fork 14
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: add check using only a CID #47
Conversation
* origin/main: chore: bump go.mod to Go 1.22 and run go fix (#51) chore: port version.go from rainbow chore: bump libp2p and kad-dht fix: make overflown text scroll chore: go-libp2p-kad-dht v0.26.1 chore: first release
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @2color! Small suggestions inline, but feel free to ship and deploy to prod 🙏
I think this is a good incremental improvement that delivers important feature (testing CID's availability without knowing specific provider).
We can enhance it in future but just shipping this as-is is already a big win for anyone trying to debug things.
ps. I did a small cleanup in #55 but it is not related to this PR.
if maStr == "" { | ||
data, err = d.runCidCheck(r.Context(), cidStr) | ||
} else { | ||
data, err = d.runPeerCheck(r.Context(), maStr, cidStr) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a blocker, but I think we may want to time-bound these with some sane timeout.
I've filled #54 to tackle that in future PR.
What's in this PR
This PR fixes #6
PeerFoundInDHT
in favour of a simpler array ofMaddrs
containing the maddrs for each provider (without the observed address count) and removingCidInDHT
which is redundant for this check (see Rename CIDinDHT to ProviderRecordFromPeerInDHT #52)Other approaches explored but decided against
Exposing a delegated routing endpoint and reusing the existing CID & Maddr endpoint
In this approach, given a CID by the user, the frontend would make a delegated routing providers request and then issue multiple check requests for each provider returned. This would make the frontend a bit more logic heavy. However, after some initial exploration, I decided against it for a number of reasons:
CidInDHT
which adds overhead to