# IPFS Companion mv3 Redesign notes ###### tags: `companion` Design notes for a better end user experience ### Notify User via browser action badge if IPFS redirect is available - In cases where we have not seen the dnslink/x-ipfs-path url we cannot redirect automatically. We add it to the "Known URLS" for declarativeNetRequest API and notify the user via badge and provide a link to "reload page on IPFS" within the popup. - setBadgeText has a maximum of 4 characters - setBadgeText accepts emoji The current MV2 version of companion uses the badge icon to display the peer count. We don't really need to show this information in such a prominent way so using as a way to notify the user of availablity of a dweb version is preferred. Brave is pretty slow when enabled against local node (it can also be slow for companion). We need some sort of visual indication to the user that we are searching the network. ### Define Gateway vs local node behavior We need to define when a user should be accessing content via a https gateway vs their local node. - What should be default behavior - How should we notify the user whether they are on gateway or local node? - mv2 allowed users to set preference between gateway / local node per domain - Durin is testing the speeds of different gateways vs local nodes on app start up. We could do something similiar - mv2 allows the user to set a preferred gateway, should we support more than one? (given the above bullet point) ### Indicate IPFS "level" to user depending on their local setup We are exploring [defining different "levels" of an ipfs implementation](https://number-zero.notion.site/Defining-IPFS-and-IPFS-integrations-1fc599790aa1424889c47d968e2db9d1) in order to enable ipfs to be available in more resource restricted environments (ie: mobile/low power). As it currently stands, when a user does NOT have kubo running locally, they would only have a level 0 implementation. This is because we [cannot currently verify the cid fully within the browser itself](https://github.com/ipfs/ipfs-companion/issues/17). We should detect the user's setup and indicate to them which level they are on. This indicator should allow the users to click/hover on it to reveal an explanation of the limitations and how they can achieve level 1/2 status. It would be ideal to share this effort across teams so that Durin, and other implementations can display this. ### Smoother flow for local content fetching There are some cases where a user tries to access some ipfs content before it has been fetched to their local node. In the case of this delay, we should show an informational splash screen to let the user know what is going on, and show a loading indicator.