IPFS support

[ShalokShalom]

IPFS is a distributed peer-to-peer network, which offers the hosting of static sites:

https://ipfs.io/ https://ipfs.io/ipfs/QmdPtC3T7Kcu9iJg6hYzLBWR5XCDcYMY7HV685E3kH3EcS/2015/09/15/hosting-a-website-on-ipfs/

Can you support it?

[Benaiah]

Editing a site which is hosted on IPFS should be perfectly feasible once you have a build process which deploys to IPFS - Netlify CMS doesn't handle building or hosting the site whatsoever, just editing the content. You should be able to set up a GitHub repo for your content and deploy the content to IPFS from GitHub however you want. The only missing piece you'd need is an auth server for authenticating with GitHub. We provide that for free for sites hosted on Netlify, but custom auth servers exist - see https://www.netlifycms.org/docs/custom-authentication for more details.

Using IPFS as a backend for your source files, which would require direct interaction with IPFS by the CMS, would be significantly more complicated. ~I don't know enough about IPFS yet to say how that would be best implemented, but unless IPFS supports pushing changes directly from the browser somehow it would require an intermediary server to push changes. If that's the case, I don't see why we'd need IPFS-specific code in the CMS.~

~If IPFS does support pushing changes from the browser, it would probably be feasible to support it. I'd be thrilled at any PRs building CMS support for it if that's the case.~

EDIT: It looks like IPFS has an official API definition, with an implementation at https://github.com/ipfs/go-ipfs. A PR adding a backend for that would be awesome, but I don't know how it would be best implemented. The simple workflow would likely be straightforward, but I'm not sure how you'd want to translate the Git-based semantics of the editorial workflow to IPFS. It'd be fine to start out by just supporting simple workflow, of course.

[ShalokShalom]

There is also a JS implementation, which runs without any specific installments such as Go or a proxy, like it is currently essential and unavoidable with the Go implementation. https://github.com/ipfs/js-ipfs

Plus, a member said "its just the commit workflow that needs changing" whatever that means. 🤷‍♂️

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ShalokShalom]

Is anybody interested in this?

[chrisschaub]

This would be a great addition, a "publish to ipfs" option. I would let github host the source, no point in re-inventing that wheel. IPFS seems like a good place for the released for finished product. And yes, very interested in this.

[ShalokShalom]

You could still host it on any source hosting platform of your choice, such as Gitea. Choice is always nice and its not hard to follow the standard that Git is. No need to make it Github specific, I guess. :smiley:

[hsn10]

Yes, I would like to have ability to publish into IPFS as well. Build process should support updating _dnslink as well. There is no need for netlify to run IPFS gateway.

[mfcodeworks]

+1 for this, not sure if it's in the pipeline but I'd love an option to publish to IPFS, maybe including IPNS for a static URL

[jikkujose]

This would be awesome!

[decebal]

+1

[woodcox]

Yes ipfs support would be great. Maybe netlify could also offer a pinning service like pinata. If there is a build process to include netlifycms that would be awesome.

[chrisschaub]

I am working on this for a client, I'll see what I can post. But as a starter, this exists:

https://github.com/ipfs-shipyard/ipfs-deploy

So once you get a "build" you can run this and it will deploy to an ipfs pinning service (supports Pinata etc.) and then it will update DNS for you! Every bulid to IPFS requires you to update your DNS, ENS, HNS etc... so that it knows where to find the new IPFS data.

This plugin, for Gatsby, doesn't really work for Gatsby v4 .. https://www.gatsbyjs.com/plugins/gatsby-plugin-ipfs/ . It is a key piece so the built files have relative paths.

[thekoenekamp]

+1