-
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
Skip unactionable providers in check #70
Comments
That this isn't happening is IIUC a bug, or at least inconsistent, behavior in boxo related to the ContentRouting interface wrapper for routing-v1 https://github.com/ipfs/boxo/blob/4af06fdc16292155a6ecb0dafa2a8c7d082a2b64/routing/http/contentrouter/contentrouter.go#L116.
|
@gammazero I thought IPNI's (or at least cid.contact's) Even if they're supposed to it might still make sense to handle deduplication in boxo to protect from buggy servers. |
@aschmahmann I thought that they were removing duplicates. Maybe it is not happening due to how streaming results are handled. Investigating. |
I thought the point of PeerSchema is to allow for flexibility without requiring explicit code changes. If we only allow PeerRecords with
We did exactly that in ipfs/specs#484, where we use |
Just to confirm, in the results above, the CID See also: ipni/indexstar#147 |
Deduplication should take place here: https://github.com/ipni/indexstar/blob/main/delegated_translator.go#L110-L137 However, if the advertised metadata is different for the different records but everything else is the same, then the records will still look like duplicates in ipfs-check because it is not showing that the metadata is different. It is common for the same provider to store the same CID in multiple deals, and therefore with only different metadata. The metadata values may have the same protocols, but still be different. |
@2color Does |
Inside of boxo there are two different APIs used for content routing:
In practice there is AFAIK no code that uses the ContentRouting interface and handles Bitswap + another protocol, so it seems fine to use that wrapper to handle just Bitswap / unknown rather than also shuffling say graphsync through it only for it to result in wasted connections for all real consumers. So when we want to start checking other protocols besides bitswap we can use the libp2p content routing interface wrapper, since we'd want to surface the protocols anyway.
|
Updated: @gammazero it looks like you're right. The metadata is different for graphsync-filecoinv1 (IIRC it contains the piece CID info). This will go away once we filter out the graphsync data though. https://cid.contact/cid/bafybeicklkqcnlvtiscr2hzkubjwnwjinvskffn4xorqeduft3wq7vm5u4
https://cid.contact/routing/v1/providers/bafybeicklkqcnlvtiscr2hzkubjwnwjinvskffn4xorqeduft3wq7vm5u4
Notice:
|
That's useful to know. Does cid.contact return any other schemas from its delegated routing endpoint? Or only
So from the perspective of the IPNI, it sounds like you don't consider this a bug. Moreover, based on @aschmahmann's response:
IIUC @aschmahmann, your suggestion is to:
What I'm still trying to understand from the discussion above is what the following looks like in practice:
Currently, the wrapper implementation is built to satisfy the go-libp2p routing interface. Does this mean that as soon as we start supporting other protocols, i.e. gateway retrieval, in Boxo, we will need to evolve the wrapper in |
Maybe, there's a few ways to make the changes but the end result is that we'll need an abstraction that allows passing more information from the content routing system into the data retrieval system. Maybe that looks like the interface we already have for delegated routing, maybe it looks like something else, we'll have to see how it goes as we start building |
Update:
|
Triage note:
|
Are you referring to boxo#587 or ipfs/boxo#678?.
Currently we use Vole to conduct the bitswap check. What should we use for providers with
How is this useful presuming that we only support |
I meant ipfs/boxo#678, sorry, we did not notice #72 before. Gist of triage discussion was that ipfs-check should filter out useless things for IPFS Mainnet by default (done in #72), but allow people to disable filtering via advanced settings (like they can change
If we want to probe HTTP, we can make trustless gateway
Mostly educational about what is mandatory, and what is optional at protocol level. For example, https://delegated-ipfs.dev/routing/v1/providers/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi has providers that use Ability to adjust filters from GUI maintains open system where new protocols can be added by people in ecosystem without being blessed by us, PLN, or anyone else. For example, someone may start announcing custom protocol on routing systems like IPNI, and use our tooling for querying / debugging. |
I agree.
I agree that we should keep things open ended and configurable. Though realistically for things new protocols to actually work in all existing tooling requires coordination, and I don't think it's within our ability to completely remove our need for coordination. Just as an example, even just adding support for http gateway retrievals require a lot of coordinated changes and it still doesn't currently work as it requires implementing support for it. -- Since this issue was mostly concerned with fixing open bugs that arose by having providers from the IPNI, I have opened a separate issue to discuss http gateway checks: #73 |
I can confirm that the the original example has been fixed in production |
Problems
Bitswap
, since bothtransport-graphsync-filecoinv1
andtransport-ipfs-gateway-http
are unsupported by both Boxo, Kubo and Rainbow.Example
Potential solutions
transport-graphsync-filecoinv1
and [transport-ipfs-gateway-http
]The text was updated successfully, but these errors were encountered: