# Protocol handler test Say you want to be able to play a video in some html5 js video player. And say the user specifies that CID in this form: `ipfs://<cid>` Now we have a problem. Does the browser know how to handle `ipfs://`? You do not want the user to provide the full `http://<gateway>/ipfs/<cid>` url because that now relies on one point of entry. It might very well be that one point, but you shouldn't have to provide it. The browser has a `navigator.registerProtocolHandler`, but i can't find a way to test if a given protocol (`ipfs` in this case) is supported by the browser. Knowing this information could help implement IPFS support in web libraries (`hls.js`, `video.js`, ...) as in the case that `ipfs` is supported you'd only have to make sure the web library handles url's like that. And in case it's not supported you could fallback to a public gateway. ## bool navigator.isProtocolSupprted(string protocol) This is just a braindump but wouldn't it be cool if there was an API like that? IPFS supporting plugins for web libraries would then have to query that function and based on the return rewrite the given `ipfs://<cid>` to something the browser understands. ## Bonus Would it be acceptable for browsers to by default use the dweb.link gateway as protocol handler for ipfs and ipns? Then show a message to the user that a default is used but the user should install a local gateway instead? Kink of like how opera supports ipfs but with the addition of a message (and a config value to change the default).