IPFS version of site (enhancement)

[laanwj]

IPFS is a "peer-to-peer hypermedia protocol", a kind of distributed CDN.

Recently the browser brave integrated native support for it, a first in mainstream browsers. It is possible that others will follow (e.g. firefox issue). There are already plugins available to integrate it in other browsers.

We might want to consider hosting bitcoincore.org on IPFS as well. As the entire site is static, it is a small step. Besides P2P protocols camaraderie, this has some advantages:

• Removes a central bottleneck (unlike the clearnet and Tor endpoints), without having to rely on "evil" anti-DoS services
• Unlke BitTorrent, it can (usefully) host the HTML pages (documentation, changelogs, news) as well
• Helps with censorship circumvention

[raucao]

FYI: I just started turning all links into relative links, in order to make the current build work on nested URLs, like e.g. on IPFS HTTP gateways. Hoping to have a PR for it sometime today, including a demo of the working site on IPFS.

[raucao]

Using the code from the PR I just opened, I ran the build and added the contents of _site to a public IPFS node of mine using ipfs add -r _site/. I have not familiarized myself with the release process for this website, but that command would be what you would want to integrate there.

The current content ID of my build is QmNxmoeixDkNyAM4FTSrpW3yHfmN1dR5yy48o7Thw8kFSf.

You can inspect the directory contents on your own IPFS node like so:

ipfs ls QmNxmoeixDkNyAM4FTSrpW3yHfmN1dR5yy48o7Thw8kFSf

Or you can show documents like so:

ipfs cat QmNxmoeixDkNyAM4FTSrpW3yHfmN1dR5yy48o7Thw8kFSf/index.html

For looking at the actual website in a browser, you can use public IPFS gateways, like e.g.:

• https://gateway.ipfs.io/ipfs/QmNxmoeixDkNyAM4FTSrpW3yHfmN1dR5yy48o7Thw8kFSf/
• https://ipfs.kosmos.org/ipfs/QmNxmoeixDkNyAM4FTSrpW3yHfmN1dR5yy48o7Thw8kFSf/

Or you could use the gateway of your own local node, of course.

The content ID will naturally change, when the contents of the directory change, i.e. whenever a new version of the website is published. There are various options for resolving the current content ID from a persistent identifier, but they all involve some level of centralization, of course.

• DNSLink uses DNS TXT records to map a domain name to an IPFS address
• IPNS, the InterPlanetary Name System, supports creating a mutable content address, which only the holder of a specific key can update

[TheBlueMatt]

Awesome, thanks for doing the legwork! How do we want to go about creating an "official" mirror? Is there an automated way or would it be best to integrate it into our current website updating flow?

[metaspartan]

Using the code from the PR I just opened, I ran the build and added the contents of _site to a public IPFS node of mine using ipfs add -r _site/. I have not familiarized myself with the release process for this website, but that command would be what you would want to integrate there.

The current content ID of my build is QmNxmoeixDkNyAM4FTSrpW3yHfmN1dR5yy48o7Thw8kFSf.

You can inspect the directory contents on your own IPFS node like so:

ipfs ls QmNxmoeixDkNyAM4FTSrpW3yHfmN1dR5yy48o7Thw8kFSf

Or you can show documents like so:

ipfs cat QmNxmoeixDkNyAM4FTSrpW3yHfmN1dR5yy48o7Thw8kFSf/index.html

For looking at the actual website in a browser, you can use public IPFS gateways, like e.g.:

• https://gateway.ipfs.io/ipfs/QmNxmoeixDkNyAM4FTSrpW3yHfmN1dR5yy48o7Thw8kFSf/
• https://ipfs.kosmos.org/ipfs/QmNxmoeixDkNyAM4FTSrpW3yHfmN1dR5yy48o7Thw8kFSf/

Or you could use the gateway of your own local node, of course.

The content ID will naturally change, when the contents of the directory change, i.e. whenever a new version of the website is published. There are various options for resolving the current content ID from a persistent identifier, but they all involve some level of centralization, of course.

• DNSLink uses DNS TXT records to map a domain name to an IPFS address
• IPNS, the InterPlanetary Name System, supports creating a mutable content address, which only the holder of a specific key can update

Hello Bitcoin Core community....We will be pinning your IPFS hashes across nodes, though if an update occurs your CID will change, so maybe we can propose adding a changelog file of each new IPFS hash of the current site/code/repo or possibly @raucao you could upload it to a new IPNS hash, which will remain the same during changes.

We registered http://core.bitcoin to host this IPFS hash, it is hosted via dnslink TXT records on the Denarius (D) blockchain. You will need Denarius DNS setup to access the site from the domain.

You can also access it via our public IPFS gateway: https://ipfs.denarius.io/ipns/core.bitcoin/ for much easier sharing and rememberability.

The domain itself is registered on the Denarius chain and uses the IPFS hash: QmNxmoeixDkNyAM4FTSrpW3yHfmN1dR5yy48o7Thw8kFSf

TXID: c34f3331a5a41b49b12418c6bca959ef43051ab99c24943131097baf4dcb35ec

[raucao]

I think it's clear to everyone here that nobody trust hashes or content coming from a random name mapping on some random blockchain. If there's going to be a DNS entry, then it should be for bitcoincore.org, and ideally the hashes would also be available in data from signed commits in this Git repository.

[metaspartan]

I think it's clear to everyone here that nobody trust hashes or content coming from a random name mapping on some random blockchain. If there's going to be a DNS entry, then it should be for bitcoincore.org, and ideally the hashes would also be available in data from signed commits in this Git repository.

Denarius is not a random blockchain, it is a trusted chain, immutable and has been functioning for over 4 years now. So you should probably do a little research.

I do not own bitcoincore.org, whoever does though, could simply setup a subdomain like ipfs.bitcoincore.org and have a ipfs._dnslink setup to your hashes as well. Yea would be good to have the file available for IPFS hash changes and dates.

[raucao]

No offense intended. It wasn't so much a direct reply as more a warning for future readers that anything on a different chain is not something official, and thus cannot be trusted without additional verification, regardless of how immutable you think this particular chain is.

Thanks for offering to mirror the content on your IPFS nodes, and for contributing. Just a note: as this hasn't been merged yet, and there are a few open questions around how exactly the IPFS version should be published (and what to do with the software package files), I would suggest for you to wait until you can mirror the real hashes once everything has been sorted out.

[metaspartan]

No offense intended. It wasn't so much a direct reply as more a warning for future readers that anything on a different chain is not something official, and thus cannot be trusted without additional verification, regardless of how immutable you think this particular chain is.

Thanks for offering to mirror the content on your IPFS nodes, and for contributing. Just a note: as this hasn't been merged yet, and there are a few open questions around how exactly the IPFS version should be published (and what to do with the software package files), I would suggest for you to wait until you can mirror the real hashes once everything has been sorted out.

Same, It could become something official, if the Bitcoin Core community wanted to. It can be verified by anyone, not asking for trust in a trustless ecosystem. Denarius is built from Bitcoin, so it is immutable, it is not simply what I "think".

Of course! Anytime! Yes we will watch the repo for any updates pertaining to this and will be happy to pin them across our nodes, the ipfs.denarius.io node is an official IPFS public gateway as well and will be pinned there, we will be happy to update hashes over time. Looking forward to this getting more attention as IPFS is truly a great tool.