Open Bug 1354807 Opened 9 years ago Updated 1 year ago

Support for the IPFS protocol

Categories

(Core :: Networking, enhancement, P3)

Product:
Core
Component:
Networking
Type:
enhancement

Tracking

()

People

(Reporter: sonichedgehog_hyperblast00, Unassigned)

References

Details

(Whiteboard: [necko-backlog])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20170317000000 Steps to reproduce: This ticket is intended to discuss the status of IPFS support, and progress on implementing it as a supported standard within Firefox. Brief description: IPFS is a new web protocol aiming to replace HTTP. It uses a mix between torrent and blockchain technology; This allows websites to be seeded by their viewers rather than being hosted on a central server, while at the same time the owner maintains editing rights through the use of private keys. This not only increases network speed and efficiency, but makes websites entirely censorship and DDoS resistant... considering they aren't hosted on any central server, and will be available as long as at least one peer remains online. Why Firefox should support this: IPFS promises to be a revolutionary technology for multiple reasons; Increasing network speeds worldwide, removing all hosting costs, and making websites secure from government censorship. However, for this standard and its goals to succeed, major websites and web browsers alike must adopt it; The average internet user won't be interested in visiting a site that requires special browsers or third-party addons to access. I suggest that Firefox does its part in mainstreaming this standard... by allowing the browser to access websites hosted through the IPFS protocol, as well as caching and seeding web pages from within the browser. Although the technology is still in early stages, it's likely to replace the HTTP protocol and eventually become the new standard... by supporting it, Firefox can be among the first browsers to understand and aid this visionary approach. More info on IPFS: https://ipfs.io https://github.com/ipfs/ipfs https://en.wikipedia.org/wiki/InterPlanetary_File_System More info on ZeroNet: https://zeronet.io https://github.com/HelloZeroNet/ZeroNet https://en.wikipedia.org/wiki/ZeroNet
Severity: normal → enhancement
Component: Untriaged → Networking
Product: Firefox → Core
Whiteboard: [necko-backlog]
Something I feel I need to make clear, as I believe I haven't in my initial posting: As its own developers have stated, IPFS and ZeroNet are still in an early stage of development, and as such not even the full specifications have been defined. My suggestion should not be interpreted as something that must be fixed tomorrow, but rather an ongoing effort to prepare Firefox for approaching this new web architecture from the browser side. On the other hand, please don't let this aspect put the initiative off the priority list. As a reminder, IPFS is being backed up by Tim Berners-Lee, the very creator of the World Wide Web! IPFS is not the garage project of a random development team, but a serious worldwide initiative to rebuild the web and fix some of its current major flaws.
Hi, thanks for your suggestions. We are aware of the potential of IPFS and are watching its development closely. We will address this topic next week at our networking team meeting.
(In reply to Valentin Gosu [:valentin] from comment #2) That's very wonderful to hear! Thank you for looking into it.
@(In reply to Valentin Gosu [:valentin] from comment #2) > Hi, thanks for your suggestions. We are aware of the potential of IPFS and > are watching its development closely. > We will address this topic next week at our networking team meeting. Would it be useful if I joined and gave an update on the browser-related work that IPFS has seen in Q1? Main areas have been URLs, js-ipfs node running in WebExt, and interop with non-browser nodes.
I think we have what we need atm. thanks.
See Also: → 1312153
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
I'd like to add the Shift project. Currently they are using "jenga" they created to convert dns traffic to IPFS. They launched their new decentralized website using IPFS on 1/1/2018. This will be a platform for hosting IPFS content. shiftnrg.org
(In reply to archael87 from comment #8) That is useful information and a good service to keep track of. Thank you for mentioning! For the purpose of this report, I'm focusing on a native IPFS implementation. To my understanding this primarily includes: - A builtin version of the IPFS daemon, for users who do not have IPFS installed system wide. - A console or special page (eg: about:ipfs) allowing IPFS commands to be input (eg: ipfs add filename). - Implementation for the js-ipfs interface, allowing IPFS specific JavaScript functions to execute from websites. Note that I'm not a specialist in how exactly they should be implemented by the browser. I simply believe they should in order to encourage and mainstream early adoption of this fantastic technology. Although IPFS is still getting there, it has matured quite a bit over the past few months from what I've seen. Currently I see no reason why it wouldn't become at least as popular as the FTP protocol in the following years, if not much more rather quickly. As such, I'm personally in favor of the idea that a builtin version of the daemon deserves at least an experimental implementation accessible from about:config for the time being. If that is considered too much, perhaps a separate branch / nightly build would be an even safer place to experiment with that, depending on the policies of those builds.
Something useful I forgot to mention: Work is already being done to implement IPFS for Firefox using an addon. This addon is called IPFS Companion, and can be found on the official addons website: https://addons.mozilla.org/en-US/firefox/addon/ipfs-companion/ Currently the extension itself doesn't do much: It offers an icon which allows you to see the status of and issue commands to the IPFS daemon running on your system. Other versions of the extension intended for different browsers (eg: Brave browser) come with a portable version of the daemon, which I understand is planned for both Firefox and Chrome once it's possible to get it working through WebExtensions. Hopefully that addon can serve as inspiration for a native implementation, making the work on such easier. I'd suggest keeping it handy and tracking updates, especially if it will support a builtin daemon at a later date.
I'm happy to announce that the IPFS Companion extension has finally added support for embedded IPFS nodes via js-ipfs to the Firefox version. It now provides builtin IPFS functionality directly within the browser, with no need to run go-ipfs system wide in order to access the network. You still need to use a public gateway for the time being (https://ipfs.io/ipfs/ rather than http://127.0.0.1:8080/ipfs/) but I understand this inconvenience will also be fixed later. I'm hoping this gets us closer to a native implementation of IPFS under Firefox and Chromium, once the code becomes ready for mainstream usage and can be implemented as a default browser feature. Very excited to see how it goes.
A huge thank you to Mozilla for adding native support for the ipfs:// protocol in Firefox 59! While this isn't a native implementation, it definitely gets us closer to that point, while in the meantime the IPFS Companion extension will have an easier time offering important features to the browser.

IMO, saying "a new web protocol aiming to replace HTTP" is completely incorrect and will cause probably 99% of people unfamiliar with IPFS to immediately believe they don't like it. Nobody wants to replace HTTP, and especially not the IPFS community either.

What IPFS will be is a new protocol like scp or ftp, etc., that will let the browser retrieve data that may contain HTML, or may contain just data for resources like images, files, videos, etc.

Important news: Brave browser announced adding native support for IPFS last week!

https://blog.ipfs.io/2021-01-21-how-we-put-ipfs-in-brave
https://blog.ipfs.io/2021-01-19-ipfs-in-brave

I continue to hold out hope that Firefox will do the same. Today we need to support the decentralized web more than ever: This move would help not just Firefox users in using IPFS hosted websites, but the goal of a free and decentralized internet. Brave's way of going about it might offer an useful model for FF to approach a potential implementation.

Status: UNCONFIRMED → NEW
Has Regression Range: --- → irrelevant
Has STR: --- → irrelevant
Ever confirmed: true
Flags: firefox-backlog?
Version: 52 Branch → unspecified

I am trying to embed image with ipfs:// link into web page, but it is not working:
https://t12.catchmedia.com/

Not sure whether it is bug or limitation of firefox+extension (IPFS Companion) interaction..

https://blog.ipfs.io/2022-01-07-web3-browsers-for-decentralized-storage

I know this is a bug tracker not an article listing thread, but I felt a need to bump this with some new perspective. I already mentioned Brave browser adding support last year: Seems Opera jumped on board and has done the same thing. I believe this is significant because, while Brave can be considered a more fringe browser, Opera is one of the mainstream and to my knowledge 3rd place after Firefox and Chrome.

Firefox could easily be the 3rd important browser to make this decision. I think it would make a lot of sense if that's exactly what will happen. Mozilla was among the groups spearheading the implementation of DNS via HTTPS and helping this new protocol go mainstream just a few years ago. I feel IPFS support is the logical next step waiting to happen.

I'd definitely like to see this implemented, IPFS absolutely will be the future if it gets the support it needs now

I am excited for this.

Severity: normal → S3

I imagine Firefox could implement IPFS support by shipping a tiny retrieval-only IPFS node.

It could work like this, there's a URL with ipfs:// protocol handler, and the "hostname" is the CID. This path, including the CID and what goes after it would be resolved by that node and served back directly

libp2p, which IPFS is based on, support many various transports, including WebSocket, HTTP(S), WebTransport and others. It makes sense to me to use HTTPS as a transport in this case

it probably also be considered a secure context since the files would be pulled from a network through HTTPS. Brave considers ipfs:// sites a secure context afaik

Supporting IPFS could also unlock native resolution of ENS-powered websites, since IPFS supports it as well, as well as DNSLink.

DNSLink adds a content verifiability layer for regular websites that were uploaded on IPFS but use regular DNS domains. Brave puts a suggestion to serve a website directly over IPFS if it detects a DNSLink DNS record, but I think Firefox could do even better by implementing a setting to serve DNSLink-enabled websites directly over IPFS, if such websites support it.

In short, supporting IPFS unlocks lots of other things beyond just the protocol itself.

In case I'd like to contribute that feature, where should I start with implementing a custom protocol scheme handler?

Adding a non-HTTP protocol is a major change to the web, and also to every aspect of how browsers are designed and implemented. Steep hill to climb.

That said, here are some things that may be useful in your quest:

  • I spent a couple of years on a retrieval-only approach for integrating IPFS into Chromium, that perhaps can be useful input for that direction. There's code, learnings and context in this and the linked posts there: https://littlebearlabs.io/perspectives/ipfs-chromium-updates.

  • IPFS+Libp2p is a lot... however, its history is a long slow decomposition into smaller parts. The most recent is splitting out addressing into a minimal subset of sane defaults, which are compatible with HTTP addressing. This might be a good starting point for retrieval-only approach. More at https://dasl.ing/rasl.html

  • The approach towards HTTP integration has changed a lot in the IPFS world, so it's worth getting very familiar to where that thinking is at. For example, the Interplanetary Shipyard team has focused a lot on approaches like the ServiceWorker gateway: https://github.com/ipfs/service-worker-gateway

  • The HTTP Gateway and Exchange sections of the IPFS specs are highly relevant: https://specs.ipfs.tech/

You need to log in before you can comment on or make changes to this bug.