ipfs-inactive/interface-js-ipfs-core

Gateway should return the peerId along with the block in the response

KrishnaPG opened this issue · 1 comments

KrishnaPG commented

When a file or block is queried from a public gateway using the hash, the gateway queries the peer nodes and gives back the content as http response.

For example,

The question is:

  • is there any way, say response header or some other way, of knowing from which peer / remote machine the gateway retrieved the content ? (in the above example my machine's peer-id)

This issue is to request the feature, where:

  • the gateway includes the source peerId in the response header (along with the block / file content in the body), and
  • the caller can then use the block, and also use the peerId to query any further blocks directly (bypassing the gateway as much as possible).

While public gateways offer flexibility, they are centralized structures, and including the source peerID in the response encourages more distributed usage (at least for programmers who want to utilize that information and build distributed retrieval paradigms)

alanshaw commented

I don't think this is possible right now. With the current implementation of bitswap there's no guarantee all the data came from a single node. Bitswap queries local peers and then the DHT and receives blocks from potentially many different peers. Peer(s) a block came from (we sometimes receive dups) are not tracked in memory or on disk.

There's also the problem of once we recieve blocks they remain in the repo until the next gc run, so a subsequent request would result in a different peer (ourself) unless we persisted information about who sent us a block for every single block we ever create or recieve.

Also, in a HTTP response, it would be difficult to communicate that information. We could possibly communicate who sent us the first block but not the rest.