[HN Gopher] A guide to IPFS connectivity in web browsers
       ___________________________________________________________________
        
       A guide to IPFS connectivity in web browsers
        
       Author : tosh
       Score  : 122 points
       Date   : 2022-02-23 12:50 UTC (1 days ago)
        
 (HTM) web link (blog.ipfs.io)
 (TXT) w3m dump (blog.ipfs.io)
        
       | akavel wrote:
       | Do I understand correctly that I still need to run either an
       | extra service outside the browser on my client machine, or some
       | service on a central server I own (the WebRTC-Star thing?) for
       | this to work?
        
         | kevincox wrote:
         | For browsers that don't natively support IPFS yes.
        
           | chalst wrote:
           | It's worth noting that native support of IPFS is usually
           | going to mean something like what Brave now does: the browser
           | manages an instance of an ipfs-go node.
        
           | unfocussed_mike wrote:
           | Is there any suggestion that browsers beyond Brave will
           | support it?
        
           | tremon wrote:
           | Will browsers that natively support IPFS automatically become
           | distribution nodes? Or is cached-but-not-pinned data not
           | served to other peers?
        
       | can16358p wrote:
       | This is nice but for more mass adoption we'll need something
       | seamless that will just be included as a script in a web page and
       | "just work" by connecting to a provider while still customizable
       | for people who want to use their own node.
       | 
       | It can even "polyfill" any IPFS paths automatically (which should
       | just be simply as replacing any ipfs:// URIs with ipfs.io gateway
       | paths).
       | 
       | For anyone trying to host pinned files behind a NAT/CGNAT would
       | it be possible to hole punch to serve paths directly? If possible
       | everything can me set up to work just out of the box with
       | minimal/no setup in browser which should be the aim.
       | 
       | In other words, we need something of an IPFS version of what
       | MetaMask/ethers.js did to Ethereum based blockchains.
        
         | dangerface wrote:
         | The current state of the browser its just not possible to do
         | p2p properly, WebRTC is the best bet and you need to trust stun
         | servers to punch NAT you need to trust a signal server to
         | connect to other peers its not real p2p so why not just trust a
         | gateway and use that.
         | 
         | Brave browser has ipfs support built in and I think there are
         | plugins for chrome and firefox without the code localy to do
         | p2p properly it doesn't really make much sense faking it with
         | WebRTC when the end result is the same as using a gateway
         | directly.
        
           | can16358p wrote:
           | Trying local node, verifying it works, otherwise falling back
           | to an external node might be the best way to go. But still we
           | need Firefox/Chrome/Safari adoption.
        
         | artdigital wrote:
         | > This is nice but for more mass adoption we'll need something
         | seamless that will just be included as a script in a web page
         | and "just work" by connecting to a provider while still
         | customizable for people who want to use their own node. It can
         | even "polyfill" any IPFS paths automatically (which should just
         | be simply as replacing any ipfs:// URIs with ipfs.io gateway
         | paths).
         | 
         | That's what Brave does built in, and other browsers with the
         | ipfs companion extension
         | 
         | When you hit a ipfs URL it's resolving it either through a
         | gateway or through your own node
        
           | can16358p wrote:
           | That's great but the problem is still Brave's market
           | adoption.
           | 
           | We'd really need some support from Firefox/Chrome/Safari trio
           | to really start adoption. Most likely Firefox, then (albeit
           | unlikely) Chrome and Safari.
           | 
           | Brave's adoption is just too low, even though I (and probably
           | a significant people here ar HN) personally think it's doing
           | the best.
        
             | rglullis wrote:
             | Look at the trends. Brave has barely 3 years since it
             | became usable enough to be a daily driver, and it has
             | already 20-25% of Firefox market share. Firefox is
             | constantly shrinking its user base, Brave is growing 40%
             | YoY.
        
               | simonw wrote:
               | Where are you finding those numbers?
               | 
               | Most global browser share numbers I could find bundled
               | Brave into the "Other" category - this was the only one I
               | found that broke it out separately:
               | https://kinsta.com/browser-market-share/
        
               | rglullis wrote:
               | - Firefox at 216M MAU:
               | https://data.firefox.com/dashboard/user-activity
               | 
               | - Brave at 54M MAU:
               | https://basicattentiontoken.org/growth/
        
         | contrahax wrote:
         | Currently working on Android + iOS apps that handle the ipfs://
         | protocol natively and allow users to upload files as well. I
         | think you're right on target RE: more protocol adoption and
         | hopefully something as simple as making the links work natively
         | and letting people upload with a simple interface will help
         | out. The IPFS extension exists for Chrome/Firefox/Opera for
         | similar functionality.
         | 
         | Out of my hands but getting more browsers than Brave to add
         | support seems like the next place to start pushing IMO.
        
       | ctxc wrote:
       | Hate it when articles don't expand on abbreviations. Yes, I want
       | to read this. No, I have no heckling what IPFS is.
        
         | robgibbons wrote:
         | It's an article about IPFS, hosted at a website also called
         | IPFS.io. Just click the logo, and it will answer all of your
         | questions.
        
         | tremon wrote:
         | https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs
         | 
         | > That last point is actually where IPFS gets its full name:
         | the InterPlanetary File System. We're striving to build a
         | system that works across places as disconnected or as far apart
         | as planets. While that's an idealistic goal, it keeps us
         | working and thinking hard, and almost everything we create in
         | pursuit of that goal is also useful here at home.
        
       | alexb_ wrote:
       | > First step involves the command line
       | 
       | This is the "web of tomorrow"?
        
         | fredoliveira wrote:
         | Well, yes - the key word in that statement being "tomorrow".
         | 
         | Technological innovation doesn't happen overnight. Browsers
         | don't get IPFS support overnight. User interfaces don't get
         | created overnight. And so, yes, sometimes it is up to people
         | who can use the command line to pave the way to, as you're
         | calling it, the web of tomorrow.
        
         | TacticalCoder wrote:
         | > This is the "web of tomorrow"?
         | 
         | I'd argue that those who never wanted to do any of these things
         | pretty much got the "web of today" they deserve.
        
         | dangerface wrote:
         | Don't worry the second step is to replace your keyboard with a
         | neural link.
        
         | tpoacher wrote:
         | 2022 is the year of <s>Linux</s>IPFS on the desktop!
        
           | legutierr wrote:
           | The truly ironic thing about this comment is that there are
           | more devices is users hands today that run Linux than run any
           | other operating system. Of the remaining devices, the
           | majority run a variety of BSD Unix.
           | 
           | All of these devices might not use a WIMP paradigm--opting
           | instead for a touch interface--but for most users, the
           | majority of the GUI interactions they have with computer
           | applications are facilitated by a Linux or Unix operating
           | system.
           | 
           | Linux won in the end, it's desktop computing that lost.
           | 
           | Maybe something similar will happen with IPFS and related
           | technologies?
        
       | captn3m0 wrote:
       | Is a first-party IPFS Web Extension a possibility? Like how it
       | would have been with the old-style Firefox extensions?
        
         | sp332 wrote:
         | It's not a standard yet, but you can try it out in Firefox
         | Nightly.
         | https://github.com/mozilla/libdweb/blob/master/Readme.md#pro...
        
           | lidel wrote:
           | These libdweb Browser Extension APIs never landed in any
           | official Firefox Nightly build. Mozilla stopped working on
           | libdweb in 2019 (https://github.com/ipfs/ipfs-
           | companion/pull/533#issuecomment...).
        
         | [deleted]
        
         | dangerface wrote:
         | Seems like its necessary to get the p2p stuff working properly
         | other wise it all just uses a gateway.
         | 
         | https://addons.mozilla.org/en-US/firefox/addon/ipfs-companio...
        
       | dpweb wrote:
       | What about upnp as an alternative to stun to achieve real p2p?
       | You may need something native to setup but would not rely on a
       | relay.
        
         | southerntofu wrote:
         | UPnP does not work on all networks (eg. double-NAT), and
         | network administrators may be afraid to allow UPnP traffic as
         | it would easily open doors to the LAN from the outside (for
         | example from a stupid "smart" device).
        
       ___________________________________________________________________
       (page generated 2022-02-24 23:01 UTC)