OK. But, going back to my comment about cheap. This claim:
> The benefit of this is that you can fetch the data from anywhere
Only works if the data I want is being replicated in many locations. But storage in spacecraft is presumably a tightly constrained resource, due to the need to use technology that's space-hardened and has an extremely good reliability record, and is therefore probably far from being both cutting edge and high density. JWST, for example, only has 68GB of storage despite being an instrument for taking high resolution photographs.
I would guess that that creates a situation that is very far from the one content-addressable storage is trying to solve. The goal isn't on-demand access to arbitrary files that are just sitting around in long term storage, because I'm guessing that, in space, there is effectively no long-term storage of data files in the first place. Instead, what you're looking to do is to get the data off of the spacecraft and down to earth as quickly and efficiently as possible, and then delete it from the spacecraft's storage so that you can make room to do more cool space stuff.
And I also don't want to be using my spacecraft's SSD to cache or replicate data for others if I can possibly avoid it. That will unnecessarily shorten the lifetime of the SSD, and, by extension, the piece of hardware that I just spent millions or perhaps even billions of dollars to build and launch into space.
And I just can't follow you as far as
> imagine being on the moon and requesting some website
because, right here right now, that is such a hypothetical situation that I have absolutely no idea why it needs a real-world demonstration of proof of concept using currently-available technology. Let's wait to see if browsing the Web from the moon leaves the domain of science fiction and becomes science reality first, so that then we can benefit from whatever technology exists in that future when we're solving the problem.
>> imagine being on the moon and requesting some website
> because, right here right now, that is such a hypothetical situation that I have absolutely no idea why it needs a real-world demonstration of proof of concept using currently-available technology.
So I just want to point out that IPFS was fairly deliberately designed to have numerous, forward-compatible features that could be swapped out in the future : like https://multiformats.io/ and in particular https://multiformats.io/multiaddr/ .
In the IPFS community, there's always been a fairly heated discussion about which bit of the entire system should be stuck with the term IPFS. Like, if you took away the libp2p protocol, and just served CIDs over http, would it be IPFS? What if you took away CAR files (the merkle-tree file format used to define multi-item content)? What if you're a private IPFS network, with no shared nodes with the public network (like https://github.com/TryQuiet/quiet ). What if you didn't use bitswap, the file transfer protocol (Filecoin doesn't use bitswap, and mostly doesn't interconnect with the main public IPFS network). What about if you didn't use a DHT to find providers of a CID. What if you're not using any of the "IPFS" software stack, but your implementation still uses bits and pieces of content-addressability as defined in the standard?
Interestingly, right now, there are a bunch of experiments going in all of these directions: I think it's fair to say that if you wanted to test out content-addressable networks across the solar system, they probably wouldn't be IPFS as it is now, but their nature could probably be described using the primitives the IPFS stack uses, and learning about what needs to change would give a useful direction to some part of the extended IPFS ecosystem.
I think the key is understanding why promotional material matters so much to crypto. Crypto operates on hype -> higher price -> FOMO -> higher price cycle. The trade is that for large holders $$$ invested in hype would return significantly higher gains. This enabled questionable coins / ICOs to get celebrity endorsements for easy money in the past. In current regime the model can still work, but with smaller returns and significantly higher execution barriers.
> Only works if the data I want is being replicated in many locations
Yes, the actual transfer won't be fetching from multiple sources unless it's replicated.
The difference between location-addressing and content-addressing is that it enables the content from being fetched from anywhere, which has uses outside of space too, as many storage solutions has already discovered since long time ago (multiple decades).
> SSD to cache or replicate data for others if I can possibly avoid it. That will unnecessarily shorten the lifetime of the SSD
Correct me if I'm wrong, but SSD lifetime is based on writes, not on reads. So you should be OK with replicating already saved data, in that case?
> that is such a hypothetical situation that I have absolutely no idea why it needs a real-world demonstration
The whole "IPFS in space" is a "utopia goal" of sorts, but aiming for it gives us benefits today.
Personally, I'd love to see a move from location-addressing to content-addressing as I'm often in locations with spotty global-internet connection and really poor latency. Sometimes, websites refuse to even try to serve me data, as it takes really long time for packets to go between where I am, and the host I'm trying to reach, so they decide to cut the connection as tell me "sorry, timed out..."
If the web was already built with content-addressing in mind, my machine could automatically fetch the content from another machine on my network, my neighbor, a dynamic cache at the ISP or wherever, anyone could serve me that data instead of that particular node with that particular IP on the other side of the world. Sharing a YouTube video between two computers on the same network would just transfer bytes on the local network, instead of reaching out to the internet. The benefits of this should be fairly obvious to anyone who is familiar with networking today.
Realistically, I don't think IPFS will be the technology that makes this possible in 10+ years, but that doesn't mean content-addressing itself is the reason why it isn't more widespread. Content-addressing been around for a long time already, and I'm sure even more and more people will realize its value over time.
> If the web was already built with content-addressing in mind, my machine could automatically fetch the content from another machine on my network, my neighbor, a dynamic cache at the ISP or wherever, anyone could serve me that data instead of that particular node with that particular IP on the other side of the world.
I don't think the lack of content-addressing is the main thing holding this "utopia" back. The bigger problem is designing P2P communication protocols that work efficiently, utilize bandwidtch fairly, are not easily attackable, do not accidentally cost peers excessive amounts of money and so on. If your neighbor is on a metered connection, I'm sure they are happy the web is not using their machine to serve you content. Even if they are not, if connections are spotty and bandwidth limited, they may not be happy if their YouTube video starts stuttering because their system is now serving you Netflix content. And when they're watching porn, they're probably happy that someone else can't easily find out which porn movie they are watching by polling nearby peers for a content hash.
Ultimately the client-server model has major advantages over peer-to-peer that are highly ingrained in our society. It is the model by which delivery has almost always worked, way before the internet.
The unstated major premise of a statement like "we need to start thinking about..." is that we aren't already thinking about it. But I don't think that premise holds in this case.
> The benefit of this is that you can fetch the data from anywhere
Only works if the data I want is being replicated in many locations. But storage in spacecraft is presumably a tightly constrained resource, due to the need to use technology that's space-hardened and has an extremely good reliability record, and is therefore probably far from being both cutting edge and high density. JWST, for example, only has 68GB of storage despite being an instrument for taking high resolution photographs.
I would guess that that creates a situation that is very far from the one content-addressable storage is trying to solve. The goal isn't on-demand access to arbitrary files that are just sitting around in long term storage, because I'm guessing that, in space, there is effectively no long-term storage of data files in the first place. Instead, what you're looking to do is to get the data off of the spacecraft and down to earth as quickly and efficiently as possible, and then delete it from the spacecraft's storage so that you can make room to do more cool space stuff.
And I also don't want to be using my spacecraft's SSD to cache or replicate data for others if I can possibly avoid it. That will unnecessarily shorten the lifetime of the SSD, and, by extension, the piece of hardware that I just spent millions or perhaps even billions of dollars to build and launch into space.
And I just can't follow you as far as
> imagine being on the moon and requesting some website
because, right here right now, that is such a hypothetical situation that I have absolutely no idea why it needs a real-world demonstration of proof of concept using currently-available technology. Let's wait to see if browsing the Web from the moon leaves the domain of science fiction and becomes science reality first, so that then we can benefit from whatever technology exists in that future when we're solving the problem.