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 ?
1 Like
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
1 Like
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.
1 Like
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.
1 Like
@ipfsme I disabled QUIC. The internet-dropping during trying to load ipfs pages seems to have stopped. Thanks for the suggestion.
1 Like
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. 
android brave doesn’t have ipfs integration yet.
1 Like
As I saw there are no buttons or actions to add or turn it on android 10 Brave browser (latest from store)
@ipfsme Maintainer of quic-go (the QUIC implementation used in IPFS) here.
There’s UDP blackholing on the internet, but it’s not very common. ~1% of connections, according to Google’s measurements.
I’d be interested in looking at QUIC traces from your node. Maybe we can figure out what’s going on. Could you run your go-ipfs with the environment variable “QLOGDIR=.” and share some of the qlog files that are generated with me?
I’ve got a few hundred json formatted log files…
Which entries/parameters are interesting or helpful?
zcat *.gz | jq [xyz]
I don’t believe my ISP is performing wholesale UDP blackholing… and my IPFS nodes generally work OK with UDP for a short amount of time. However, long running nodes tend to bog down and both my LAN as well as WAN connections slow considerably. Eventually I’ve had to bring down my whole Intranet infrastructure including routers and various file servers.
Once QUIC is disabled, all of the bogging down issues disappear… So, it’s definitely caused by running IPFS nodes with QUIC enabled. But, the logs might not show any issues until I have network problems. Perhaps my ISP is doing some sort of active traffic filtering or rate limiting on UDP… Perhaps running a couple of IPFS nodes looks like a DDOS attack from/to my IP…
1 Like
qlog files can be viewed using qvis (you’ll need to extract them before uploading them).
What would be interesting here pretty much depends on what your ISP is doing. If you see that after booting up your node, the first few minutes QUIC connections work fine, and after that time you run into connection timeouts, that would be a pretty clear sign of your ISP blacklisting you.
Other forms of interference might be harder to detect. For example, instead of blacklisting you entirely, they could just drop a certain fraction of the QUIC packets you send. This would be interpreted as congestion by QUIC’s congestion controller, and dramatically reduce your bandwidth.