Both HTTP and IPFS have their merits as URL schemas. Both serve to identify a specific resource, but they differ in one important way: HTTP URLs can change what they point to. When a server goes offline, or a webpage changes, the HTTP identifier remains constant, but the resolved resource changes. IPFS on the other hand, uses a hash of the content as its identifier, which means that the resolved resource is immutable. HTTP can link to things that change, such as your current profile picture, and IPFS can link to things that never change, such as the profile picture you had at one specific moment. When linking to a resource, users could use either. But that means they have to decide what they think is more important: the current version, or the latest one.
whyDontWeHaveBoth.jpg
IPFS identifier as query parameter in URL
If we were to include the IPFS ID in the query, the client could decide which one to use.
Basically, we get a URL like this: https://atomicdata.dev/someresource?ipfsid=QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdD. That way, the subject contains information about who is in charge / where you should fetch the data (atomicdata.dev) and also, which version was used (ifps is a hash of a specific version) and where you can retrieve that data if the HTTP url does not resolve.
HTTP identifier in IPFS body
This means primarily using IPFS identifiers, and requiring that the client resolves these before allowing it to find the latest version. This makes IPFS a potential performance bottleneck.
Both HTTP and IPFS have their merits as URL schemas. Both serve to identify a specific resource, but they differ in one important way: HTTP URLs can change what they point to. When a server goes offline, or a webpage changes, the HTTP identifier remains constant, but the resolved resource changes. IPFS on the other hand, uses a hash of the content as its identifier, which means that the resolved resource is immutable. HTTP can link to things that change, such as your current profile picture, and IPFS can link to things that never change, such as the profile picture you had at one specific moment. When linking to a resource, users could use either. But that means they have to decide what they think is more important: the current version, or the latest one.
whyDontWeHaveBoth.jpgIPFS identifier as query parameter in URL
If we were to include the IPFS ID in the query, the client could decide which one to use.
Basically, we get a URL like this:
https://atomicdata.dev/someresource?ipfsid=QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdD. That way, the subject contains information about who is in charge / where you should fetch the data (atomicdata.dev) and also, which version was used (ifps is a hash of a specific version) and where you can retrieve that data if the HTTP url does not resolve.HTTP identifier in IPFS body
This means primarily using IPFS identifiers, and requiring that the client resolves these before allowing it to find the latest version. This makes IPFS a potential performance bottleneck.