Instead, IPFS uses content-addressing, where the content is hashed and given a ID based on the content itself. So "foo" could have the ID A, while "bar" could have the ID B. No matter who added the content to the network, if the content is the same, the ID will be the same.
The benefit of this is that you can fetch the data from anywhere, and you'll get the data you wanted guaranteed (assuming the content is available somewhere on the network).
In terms of space, imagine being on the moon and requesting some website. With location-addressing, you have to be able to reach that particular node, and the data has to travel from there to you. With content-addressing, that content can be fetched from anywhere, maybe another node on the moon has it already, so it can fetched quicker from there, or some node in-between the moon and earth.
More reading about content-addressing: https://en.wikipedia.org/wiki/Content-addressable_storage
Magnet links and git are two fairly common technologies that uses content-addressing with lots of benefits.
(edit: of course, this is a simplification of both how IP, networks, IPFS, DNS and more works, but I hope it provides a fair overview at least)
> 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.
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.
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.
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.
You can add distributed caching to HTTPS with message signatures (or a similar scheme): https://httpwg.org/http-extensions/draft-ietf-httpbis-messag...
Imagine shipping an IPFS node to Mars and being able to have content consistency
See, for example, DTN, which is already being used to do real work on the ISS. There are also plans use it elsewhere, including in some future lunar missions. https://www.nasa.gov/communicating-with-missions/delay-disru...
CAS is a separate issue than a caching hierarchy.
CDNs usually offer location-addressing, sometimes via different ways but most of the time boils down to "I have to reach that specific node to fetch this specific content". I'm not sure in what other words I could use to explain how content-addressing is different from that...
(not even talking about IPFS at this point (or in my grand-parent comment), it's just about URIs vs URLs in the end)
(edit: besides, the CDNs you're talking about are with 99% certainty using content-addressing all over the place internally)
Also, even for a peer-to-peer network, you still need some way to discover the peers that actually have the data, so you need some kind of centralized infrastructure that can help coordinate. Ultimately whether you connect to a CDN or to the centralized P2P facilitator is not such a massive difference.
Also, given the way ISPs typically operate, you will probably have much better bandwidth downloading from a centralized server than from a generic other end-user.
This is why BitTorrent only really has two successfully deployed use cases:
1. Windows updates and similar, where machines can rely on broadcasts on a small LAN to coordinate without needing more complex infrastructure (doesn't scale beyond LAN)
2. "Piracy", where the major advantage is that it diffuses the blame for copyright infringement, instead of presenting a single large target that holds all of it.
Reality is the space thing is just part of the usual crypto grift narrative building.
Being able to arbitrary place caches anywhere and let anyone serve the data, and you can trust you're getting the right data, is a huge benefit over location-addressing. Ignoring IPFS, content-addressing makes sense for so many things, which is what lots of storage/caching/CDN solutions have discovered decades ago.
Content-addressing is nothing new (nor did Protocol Labs/IPFS "invent" it) and if you're using a CDN to serve content today, the CDN is with 99% certainty using content-addressing at least internally.
This is the grift.
The "libertarians" want to be able to host their CSAM, sorry, their "freedom materials" on everyone's servers in such a way that nobody can ever "silence their freedom" because it would mean silencing the cat gifs, too. Want to be "on the net"? Well, you absolutely have to agree to host anyone else's content without question at all times. But, it's okay, we'll pay you with... coins!
Besides, how on earth is your argument even relevant when we're talking about content-addressing as a whole, without involving IPFS at all?
Lots of things use CAS, not just IPFS.
The specific case you outline can be served by existing technology, without having to introduce magic coins, beans, or other distractions.
I was pretty interested in IPFS prior to it being overtaken by web3 grifters.
Or once its in the network thats it?
Seems easy to DDOS by changing one character many times in a file which generates a new id each time
The same as you'd delete anything from any protocol essentially, you delete it locally. If you've shared it on the internet, you ask people nicely to delete it, if they refuse, you either pursue them legally or give up. Basically, just like how you delete a picture from the internet today.
> Seems easy to DDOS by changing one character many times in a file which generates a new id each time
All you're doing in that case is adding more files locally and filling your hard-drive with random files. No content gets automatically distributed unless people request it.
This complete nonsense. First of all DNS can give you multiple IP addresses[1] (that's how CDNs work eh!) and then IP addresses are only very loosely coupled to geographical locations…
[1]: https://www.cloudflare.com/learning/dns/what-is-anycast-dns/
Edit: I removed the "geographical" from the "pointing to a IP which has a specific geographical location" part. Hopefully it'll make things clear enough while not over-simplifying it.
The same thing could be applied to space.
The only thing I can find from official resources is documentation saying IPFS does not do that at all. Example from https://docs.ipfs.tech/concepts/what-is-ipfs/#what-ipfs-isn-...
> What IPFS isn't
> IPFS is not ... A storage provider: While there are storage providers built with IPFS support (typically known as pinning services), IPFS itself is a protocol, not a provider
Reading your link I don't quite understand how come they claim IPFS is both a protocol AND a network of nodes AND not a storage. For example TCP is a protocol, but TCP is not a network of nodes even if there is a network of nodes using TCP to communicate.
I think this is some cheap wordplay to play pretend distributed filestorage and but also absolve themselves from any responsibility in case something goes wrong "IPFS is only a protocol, you probably was holding it wrong".
Sounds like those people either don't understand what they're saying, or they're mindlessly shilling for Filecoin. Both are obviously shitty, but I don't think it's fair to point the team behind IPFS in a bad light because of what others say about it.
> I don't quite understand how come they claim IPFS is both a protocol AND a network of nodes AND not a storage
IPFS is a protocol, IPFS is also the name of the network. IPFS doesn't automatically distribute data, hence it's not "storage", but a protocol for doing storage.
In the analogy to TCP, TCP/http are the most common protocols, and the most common network is what we call "Internet". Initially, there was many competing networks, until eventually The Internet overtook all the other networks and essentially "won".
(edit: again, gross over-simplification about the history the internet and more, hopefully won't be too misleading. Better overview can be found here: https://en.wikipedia.org/wiki/History_of_the_Internet)
ipfs is not a fileserver. but you can use it to host files.
Start thinking that way and it will take you to a whole new universe.
"there is no GUARANTEE about file preservation there at all (unless you pay to people hosting your files specifically)"
Sure your files are accidentally still present in the cache. Good for you. The problem is deceiving other people who may think it's somehow spacemagically-interplanetary guaranteed.
It doesn't guarantee that the content the ID resolves to is available, but once you have a content-addressable ID, you can be sure you'll be able to get the data as long as the data is available somewhere on the network.
The throughput probably won't be great, but mainly if we assume 1:1 not broadcast connections! There will be roving access, not continual, to a given satellite - a fact until there are thousands of other satellites also serving ipfs. Costs will be high.
But still, there are wins. So far, satellite reliability is fairly high; there haven't been natural or human-made disasters afflicting many satellites. In some conditions the roving nature of the satellite could be a boon; you can get information out to a lot of people.
Wikipedia, news, important events... those would all benefit from guaranteed-reoccuring-availability model, perhaps. This would be an interesting tamper-resistant way to store something like votes, if it could be vetted. If there's satellite to satellite communications, the ability to have an expanding archive of crucial orbital information is useful; the swarm can grow & update vital behavior with ipfs in interesting ways.
Rather than assess just on whether this will make a good ipfs node as ipfs is typically used (high bandwidth, high storage nodes), I think it's worth considering this on the merits of what this technology offers that is distinct. Pulling out a single ruler to measure everything isn't always the best and only way to judge; indeed I think we miss a lot when we apply only our current set of expectations to new ideas & encounters. I'd encourage a more liberal consideration. Although I agree, I'm not sure either what the killer use is, I want to see thinking that pioneers what could work, that explored what values are on offer, even if it's not the same old values as the incumbent (fiber optics on the ground).
This seems like the kind of application that works best when bandwidth and storage are cheap, and I would have assumed that that, in space, both are about as far from cheap as you can get.