I am really new to the ipfs. What I noticed was some random hiccups on the speed of my internet connection, while the ipfs companion extension on brave was active. Is this something normal and expected?
I’d say it depends. Download speed depends on how many peers are providing the content you are looking for. If you are browsing popular content like ipns://en.wikipedia-on-ipfs.org then you will most likely get it faster than if you are fetching something that is provided only by a few or one peer, as it takes longer to find a reliable provider.
I know with earlier versions of IPFS (not sure about IPFS Companion) just by installing IPFS and starting it, you would notice a massive amount of bandwidth being consumed, even when you aren’t downloading anything. Clearly the rest of the network is just “making use of” it’s newfound resources. lol.
In my docker instance, the solution was to set routing to “dhtclient” and/or profile to “lowpower” to stop it from hogging resources, but for some reason the default settings were to just go ahead and hog. I think the philosophy was sort of like with BitTorrent, where simply being a part of the network means they want to go ahead and use your resources.
The default config of go-ipfs daemon is optimized for server use.
IPFS Desktop and Brave come with custom configuration tailored towards desktop use and consumer-grade networks (lower number of maintained connections, smaller datastore, enabled GC etc).
Regarding older versions, could be:
- Old versions of ipfs-webui preloaded a lot of geoip data from IPFS, which produced huge traffic spike and gave users the impression that IPFS is expensive to run.
This has been fixed and geoip lookups are executed only when the user opens Peers screen. - go-ipfs 0.5.0 enabled AutoNAT service by default, making nodes switch to DHT server only when it makes sense. This switched many go-ipfs nodes to dhtclient mode (even if they had no
--routing=dhtclient) and decreased the “ambient metadata traffic” significantly.
Another trouble I am having with trying to use ipfs on brave via ipfs companion is this:
Trying to download a pdf file (1) via ipfs network isn’t resolving in anything. My ipfs companion currently has ~200 peers. Ipfs node type is “Provided by Brave (experimental)”. Use Automatic mode is disabled (I want to strictly use my own local node). Use Local Gateway is enabled. Use Subdomains are enabled.
However, the ipfs tab is just keep loading (waiting for localhost…) without actually downloading the pdf.
Pre-Post Edit: I was tinkering around the ipfs companion extension settings while using this. Is enabling/disabling Load DNSLink Sites from Custom Gateway setting can have an effect?
(1): ipfs://bafykbzaceb43wll5uu223jj4bucisq43klu7hzo3ih4etkre3o2boxdkjtebs?filename=Peter%20M.%20Birns%2C%20%20Peter%20M.%20Birns%2C%20John%20C.C.%20Muster%20-%20UNIX%20for%20people%20_%20a%20modular%20guide%20to%20the%20UNIX%20operating%20system%20_%20visual%20editing%2C%20document%20preparation%2C%20%26%20other%20resources%20%281985%29.pdf
Can your PDF be downloaded by some other gateway like ipfs.io, using http? Can your Brave ipfs:// work on any files you know also work already via ipfs.io on http ?
Thanks for this feature! I’m currently having a little play with it and it seems really good!
I’m working on building a platform on top of IPFS just now, as we are still early and trying to stay stealthy we are running our own IPFS network with a custom set of bootstrap servers and a swarm key.
I had a little look through the config settings and I can see how to get access to the node to tweak that such as setting the new bootstrap servers. What I couldn’t spot was a way to load in a custom swarm key. I wonder if this is possible?
It would greatly simplify demos for our prospective users if we can tell them “just install brave and use this config”. We do manage fine using wss connections to a server just now but it would be really neat to have people running local nodes so they have their own local persistent cache, but also to remove the reliance on the in browser js-ipfs nodes and webrtc setup.
I understand this isn’t a primary use case, it would be super handy for us though.
Thanks again!
Checked to download the same file on Firefox without ipfs. And Firefox is also on stuck on keep loading. Perhaps it’s a problem with the file’s availability on ipfs, rather than a fault on the Brave ipfs extension.
I haven’t tried downloading a pdf that I know of from ipfs network. I just started using ipfs! 
I should have dug more before asking - if anyone else is trying to get the brave IPFS node to connect to a private network, you can find Braves copy of ipfs in ~/.config/BraveSoftware/Brave-Browser/brave_ipfs/, adding the swarm key there and updating the bootstrap servers in the config has allowed us to join the Brave browser node to our private network.
This is really awesome, well done!
Curiously this didn’t break braves ability to handle urls from the main IPFS network, I guess it is falling back onto the backup gateway.
Apart from the issue I mentioned before, one consistent thing seems to be, when I go to an ipfs link, is large drop-down in my internet connection. Other tabs in my browser, also other programs using the internet connection, lose their internet connection, while the ipfs tab keeps on the loading.
This is one of the reasons I disable QUIC … in some cases, I’ve experienced local flooding of UDP packets… My ISP also seems to be performing some type of traffic filtering/blocking.
After disabling QUIC, I can run multiple IPFS nodes per LAN host without too many issues.
To disable QUIC… modify the config file as follows:
...
"Transports": {
"Multiplexers": {},
"Network": {
"QUIC": false
},
...
Per documentation:
https://github.com/ipfs/go-ipfs/blob/master/docs/config.md#swarmtransportsnetworkquic
Thanks for the answer.
My computer has always on VPN – thus I don’t think I have an ISP doing blocking on my ipfs connections.
The VPN connection might actually be the problem. Depending on the vendor or how everything is set up, UDP packets might not traverse the VPN tunnel.
Try disabling QUIC and see if it fixes your problem.
Is there a downside to disabling QUIC?
All other things being equal, IPFS network interaction will be slower when QUIC is disabled.
However, I’ve had issues with UDP which result in IPFS becoming mostly non-functional. So, in my case it’s “slow” but functional or mostly non-functional.
@ipfsme I disabled QUIC. The internet-dropping during trying to load ipfs pages seems to have stopped. Thanks for the suggestion.
Feature Requests
- A useful feature would be the ability to decouple the IPFS node with the gateway selection option.
I’d like to have Brave turn on and off a local IPFS node within the Browser directory structure that I can use to quickly add web pages as I browse the Internet… but then automatically view those pages on a public gateway of my choice without messing with IPFS Companion…
- It would be good to have a pinning service selection option in the settings. Maybe partner with Pinata or something to have a drop down menu with “Pinata” and “custom”
So based on reading this thread, sounds like you’ve isolated the problem to where it’s either some network problem (like routers, ISPs, etc) or else the file just isn’t being served up by any gateways.
So pick some example file, like from the IPFS getting started guide, and make sure you can access it thru https+Firefox first, and then go to Companion next, and only once you have both those working, then move to your specific PDF file as the last step.
I am on the Brave Browser and your file wouldn’t work with the shields up, looks like the default shield settings were blocking ipfs on this page.
trying on android here.
complete newbie to ipfs.
very happy to see the integration with brave first! (hope kiwi browser could be the next…)
however,
going on brave://ipfs
with stable, beta, and nightly: ERR_INVALID_URL
could really use a simple demo page and link to it for easier testing, though. supposing the above error shouldn’t matter.
but i guess it’s still not done.
found a link.
ipns://blog.ipfs.io
it only seem to work on opera, for easy android usage today. 