3 ms·

> the gateway is in full control and can inspect and tamper with the data as much as it likes Inspect, yes, but tamper? IPFS content IDs are hashes, so it seem

> the gateway is in full control and can inspect and tamper with the data as much as it likes Inspect, yes, but tamper? IPFS content IDs are hashes, so it seems like it should be possible to verify what you have been sent if you really cared enough to do so.

danpalmer 4y ago
Possible, yes, but probably the most widely used IPFS implementation – the Brave browser – does not implement this yet. They say they plan to in the future.
- cowtools 4y ago
  I would think that the browser plugin + daemon is the most common implementation.
georgyo 4y ago
IPFS content IDs are hashes of the DAG of the content. That DAG chucks up the data and includes it directly in itself. There isn't a tool today that can verify an IPFS address without actually downloading that file's DAG, which is basically downloading the entire file.
- dark-star 4y ago
  That's what he said: you can veify the file's hash after you downloaded it, to make sure it wasn't tampered with...
  - sneak 4y ago
    The merkle root of the DAG over the chunks is not related to the file's hash. Imagine if I gave you a file out of a git repo, and the long commit hash. It's insufficient on its own to verify integrity, you need the intermediate nodes. With ipfs you can infer that it used the reference chunker and try to reproduce the DAG but there is no guarantee it will work. Better to just speak ipfs to the p2p net and get the DAG.
    - georgyo 4y ago
      Exactly, and it is even worse than git. Git the Merkel root is a list of directories and hashs of whole files. Ipfs, an individual file can be made up of many trees and those trees can have trees. Example: https://explore.ipld.io/#/explore/QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T https://explore.ipld.io/#/explore/QmbGtJg23skhvFmu9mJiePVByh... That is a single file, but good luck verify that file without actually downloading the entire dag tree which includes the file. Worse, that same file can be chucked and bucketed infinitely number of ways. So if I download that file and the re-add it to IPFS, I will very likely get a _different_ address. And that address will likely share _none_ of the of the nodes from the previous address. Meaning even though the same file is in IPFS, they are completely distinct and don't actually help seed each other.
deleted 4y ago
[deleted]

danpalmer 4y ago

Possible, yes, but probably the most widely used IPFS implementation – the Brave browser – does not implement this yet. They say they plan to in the future.

cowtools 4y ago
I would think that the browser plugin + daemon is the most common implementation.

georgyo 4y ago

IPFS content IDs are hashes of the DAG of the content. That DAG chucks up the data and includes it directly in itself. There isn't a tool today that can verify an IPFS address without actually downloading that file's DAG, which is basically downloading the entire file.

dark-star 4y ago
That's what he said: you can veify the file's hash after you downloaded it, to make sure it wasn't tampered with...
- sneak 4y ago
  The merkle root of the DAG over the chunks is not related to the file's hash. Imagine if I gave you a file out of a git repo, and the long commit hash. It's insufficient on its own to verify integrity, you need the intermediate nodes. With ipfs you can infer that it used the reference chunker and try to reproduce the DAG but there is no guarantee it will work. Better to just speak ipfs to the p2p net and get the DAG.
  - georgyo 4y ago
    Exactly, and it is even worse than git. Git the Merkel root is a list of directories and hashs of whole files. Ipfs, an individual file can be made up of many trees and those trees can have trees. Example: https://explore.ipld.io/#/explore/QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T https://explore.ipld.io/#/explore/QmbGtJg23skhvFmu9mJiePVByh... That is a single file, but good luck verify that file without actually downloading the entire dag tree which includes the file. Worse, that same file can be chucked and bucketed infinitely number of ways. So if I download that file and the re-add it to IPFS, I will very likely get a _different_ address. And that address will likely share _none_ of the of the nodes from the previous address. Meaning even though the same file is in IPFS, they are completely distinct and don't actually help seed each other.

deleted 4y ago

[deleted]