Is there a way to know the peerId from the gateway response?

Help
1

Appreciate any info / pointers for this question: https://stackoverflow.com/questions/56208233/how-to-know-from-which-node-the-file-block-was-retrieved-when-querying-https

When a query is made to public gateway, such as, https://ipfs.io/ipfs/QmXjFR1MiAMYprPjwLQwXXonYK52FihQVEL6a2dh3uhUey (which possibly resolves to my local node), is there any way, say response header or some other way, of knowing from which peer / remote machine the gateway retrieved the content ?

Is there anyway, the gateway can be asked to give just the peerID, and not the actual content, so that I can directly connect to that node and get the content, rather than gateway retrieving it (possibly from me / my node), and sending it back to me (as http response) ?

2

Some gateways are writable, ( https://siderus.io/ipfs/ is ) and are allowing you to push the content directly.

A way to discover a gateway peerID is to upload an unique random content and then asking the network who has the content ( ipfs dht findprovs IIRC ).

If you want to connect to Siderus gateway edge nodes you can use this bash quick command:

curl https://meta.siderus.io/ipfs/connect.sh | bash

This will speed up the connection when you are using the gateway

3

Thank you. The question was more about retrieving the peerId of the machine that is holding the content (from which the gateway retrieves it).

For example, you hold some content, and I query the gateway for that content, and the gateway gives me the content (retrieving it from you). My question is, is there a way the gateway can inform me, that this content was retrieved from you (your peerId).

Right now, it looks like the content is coming from the gateway, where as in reality it is retrieved from some other peer and supplied, and there is no way to identify from which peer it was pulled and supplied (at the receiving end).

4

I left a response on the post (https://stackoverflow.com/a/56247939/127977), but I’ll x-post it here:

I think the answer is no (as of v0.4.20). The process IPFS goes through when retrieving a block is:

  1. Do the following at the same time:
  2. Notify all current peers that you want the block (e.g. QmXjFR1...)
  3. Ask the network to find providers of the block you want (e.g. QmXjFR1...)
  4. If a peer has the block, it will send it over and you will disregard any providers that are found.
  5. If no peer has the block and a provider is found, then the provider is added as a peer and is notified that you want the block (e.g. QmXjFR1...), at which point the peer starts sending the block over.

In theory, if you run the IPFS node you could maybe do things to determine what peer a block is coming from. But the gateway doesn’t offer that information through its interface AFAIK.

Anyway, I don’t see anything in the response headers. Here’s an example from hitting the gateway API:

λ curl -v https://gateway.ipfs.io/api/v0/cat/QmT78zSuBmuS4z925WZfrqQ1qHaJ56DQaTfyMUF7F8ff5o
*   Trying 2602:fea2:2::1...
* TCP_NODELAY set
* Connected to gateway.ipfs.io (2602:fea2:2::1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=ipfs.io
*  start date: May  7 21:37:01 2019 GMT
*  expire date: Aug  5 21:37:01 2019 GMT
*  subjectAltName: host "gateway.ipfs.io" matched cert's "*.ipfs.io"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7ff002806600)
> GET /api/v0/cat/QmT78zSuBmuS4z925WZfrqQ1qHaJ56DQaTfyMUF7F8ff5o HTTP/2
> Host: gateway.ipfs.io
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< server: nginx
< date: Wed, 22 May 2019 04:32:43 GMT
< content-type: text/plain
< vary: Accept-Encoding
< trailer: X-Stream-Error
< vary: Origin
< x-content-length: 12
< x-stream-output: 1
< access-control-allow-origin: *
< access-control-allow-methods: GET, POST, OPTIONS
< access-control-allow-headers: X-Requested-With, Range, Content-Range, X-Chunked-Output, X-Stream-Output
< access-control-expose-headers: Content-Range, X-Chunked-Output, X-Stream-Output
< x-ipfs-pop: gateway-bank2-sjc1
< strict-transport-security: max-age=31536000; includeSubDomains; preload
<
hello world
* Connection #0 to host gateway.ipfs.io left intact
5

Thank you. Opened a request for including the source peerId information in the response somehow: https://github.com/ipfs/interface-js-ipfs-core/issues/476