Will

I suspect https://github.com/ipfs/boxo/blob/main/routing/http/client/transport.go#L24-L28 could be an issue: * if the response body is not fully drained, the http client will not be able to re-use the connection. eventually you'll run...

* there may be records with >1MiB of response > bitswap issues a query for 10 providers and the accelerated DHT returns 20 immediately, terminating the query before it even...

~30% of queries to kubo on gateways end up timing out with no peers, so we should still see those at minimum reaching the indexers, right?

i would push to get an RC onto bifrost and validate things are working as expected before releasing

Do we have a sense of what multipler of traffic to DHT, IPNI will be associated with removing the search delay?

cc @masih * I believe IPNI can handle a 10x increase on reads. * Do we have a sense of if there are intermediate solutions that result in less read...

cross posting from #9530 since i missed it here. https://github.com/ipfs/kubo/pull/9530#issuecomment-1385777419 no need to not increase indexer usage at the same time as DHTs. Presumably any increase in queries is an...

Flagging some where we some thought is going to be needed: Things that are highly depended on: * github.com/ipfs/go-cid * github.com/ipfs/go-datastore * github.com/ipfs/go-ds-* * github.com/ipfs/go-log Things that aren't 'ipfs owned':...

> We believe that putting IPFS things in one place ... will result in a much better experience for other devs You've gotten concerns from other devs on this transition....

Thanks for raising How do you imagine compression / access working? Would you imagine compression being applied per-block, or would you imagine a CarV2 index that's able to provide offsets...