nabu VS multiaddr

The block auth is very generic, just an extra top level key in cbor maps or a small prefix in raw blocks. The protocol is S3 V4 signatures.

There is a Java implementation of the modified bitswap for this in Nabu [0] and a Go one in ipfs-nucleus [1]. With both of these you can use whatever auth verification protocol you like.

[0] https://github.com/peergos/nabu

[1] https://github.com/peergos/ipfs-nucleus/

> 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'm not sure where they are coming from, but this looks like related to this project: https://github.com/multiformats/multiaddr

If you want people to be able to connect to your gateway via ipfs swarm connect /dnsaddr/ipfs.example.org, then you need to add some TXT records. You can type ipfs id to get the list of addresses associated with your node.