DAdannyobrien·Jan 16, 2024
>> 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
Read the rest
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.