ipfs-companion VS multiaddr

I appreciate you documenting this, if it's not too much hassle, can you please create an issue here: https://github.com/ipfs/ipfs-companion/issues/new/choose also adding at what steps things didn't work for you and what would've made your experience better?

I am sorry that I couldn't be of more help. Perhaps cloning the github repo https://github.com/ipfs/ipfs-companion, entering developer mode, and manually creating an extension will resolve your issue.

I'm also going to assume you've used ipfs before. If not, then take some time to discover IPFS with IPFS Desktop, IPFS Companion and go-ipfs!

Mozilla stopped working on libdweb in 2019 (https://github.com/ipfs/ipfs-companion/pull/533#issuecomment...).

An IPFS node is a software that can communicate using the IPFS protocol. For example, Go IPFS, JS IPFS, IPFS Desktop (which may use Go IPFS in the background) and IPFS Companion (which may use JS IPFS in the background).

> 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.