Rework Dapp Connection Screen

[smaroudasunicorn]

Below an image is presented about dapp connection

We need to rework dapp connection screen. This screen is about dapp requesting from the wallet to provide address of active account. Should not seem like a transaction.

• Identicon should not be created for the URL
• Allow Access is misleading, since we do not providing access to the wallet here.
• Concrete explanation shall be displayed, we are not connecting to the account, we are getting the address of current account.
• Site URL should not be displayed 2 times

[onvisions]

Dapp Connection Screen

CASE 1. The dApp name can be fetched, the URL can be fetched, dApp favicon/logo can be fetched and displayed.

CASE 2. The dApp name can not be fetched, dApp favicon/logo can not be fetched and displayed so we are replacing it with the generic label "DAPP" and generic icon.

CASE 3. Unknown URL! Rare case that can still occur. URL cannot be fetched by Superhero Wallet. In this case neither the favicon nor the dApp name will be available. Most probably it's a risky app with basically "unknown source". User should be warned about potential risks.

Figma reference: https://www.figma.com/design/3oGLWzSH0oJljo4RETZtur/Superhero-Wallet-UI-(%E2%9C%94%EF%B8%8FUpdated)?node-id=37239-260033&node-type=frame&t=xkVASfrr0tXWPBQs-0

[onvisions]

@sotiris @CedrikNikita IMO there's an issue with the way we grant permission to third party dApp to view not only the current account but also all "current active accounts" in the future. In other words the dApp asks only once for permission to view current address but it will be able to view all "currently active addresses" until Superhero Wallet is connected. @CedrikNikita correct me if I'm wrong here.

I am concerned that the user is not aware what's happening. As a user I'd expect to give permission affecting only my current account address when connecting, logging in, providing permission to a dApp or platform.

I might want to use different accounts for different platforms and purposes. I would not expect to grant access to the dApp to view all my wallet account addresses and that's what we are currently doing. I think we should reconsider this behavior and ask for permission each time the currently active account is changed.

[smaroudasunicorn]

@onvisions dapp requests access to one address is not this the case?

[onvisions]

@onvisions dapp requests access to one address is not this the case?

As far as I understood this is not the case and that's why I raised my concerns from user perspective. Let's sync with @CedrikNikita to be on the same page if it's needed.

As far as the current task is concerned I have created the design according to request:
the dApp is asking for permission to view user's currently active account address (the address that is active at the moment of granting the permission).

[peronczyk]

@onvisions , @smaroudasunicorn - I confirm that the DAPPs are actually connecting with the wallet, not the addresses. For AE if a DAPP is connected whenever user changes the active account the DAPP knows about that and can make an action based on this action. The best example is our testing DAPP: https://docs.aeternity.com/aepp-sdk-js/v13.3.2/examples/browser/aepp/

Try to connect and open the "Basic functionality" tab. Then open the extension and try to switch accounts. You'll see that the testing DAPP will update the active account on the fly.

This is why I agree with Tsvetan that this connect modal is not fully informative.

MetaMask is asking you to list the accounts you want to use for connection:

[peronczyk]

Dapp Connection Screen

CASE 1. The dApp name can be fetched, the URL can be fetched, dApp favicon/logo can be fetched and displayed.

I suggest to not put the dapp name (eg.: Superhero Dex) as a tag above the arrow. There is a limited space in this area and in my opinion putting the name there gives more risk of breaking the layout than a real value to the user.

Also regarding the icon: should we create our own list of icons we can display? I'm asking because the situation is the same as with the app browser: we are not able to obtain the dapp icon.

---

CASE 2. The dApp name can not be fetched, dApp favicon/logo can not be fetched and displayed so we are replacing it with the generic label "DAPP" and generic icon.

The tags above the arrow are uppercased, so we are not able to display "dAPP". What do you think about using "DAPP"?

Also the "dApp" string displayed as the name is our own label which should be used when there is no name?

---

CASE 3. Unknown URL! Rare case that can still occur. URL cannot be fetched by Superhero Wallet. In this case neither the favicon nor the dApp name will be available. Most probably it's a risky app with basically "unknown source". User should be warned about potential risks.

Not sure if this is possible. We always have the access to the URL of the app that tries to connect. @CedrikNikita am I right?

[peronczyk]

Also I see following issues in provided designs:

1. I think reusing the transaction details header section is bad because it forces to display the DAPP data (name+address) in a narrow column which is problematic with long names and addresses.
2. The dapp name and address are displayed twice: both in the header and in the area beneath it.

As we have 100% control on the connection modals we can display those screens in totally different way than the transaction details. What do you think about following structure:

This is a working POC done with the code and it didn't require much time to do. Obviously this is only a concept and can be further updated.

[onvisions]

1. About duplicate info:
   

I agree about this one we might get rid of:

2. About the fact we are currently not able to fetch the icon/favicon of any dApp - my suggestion will be to create and keep icons for a list of known and trusted dApps (like Superhero DEX) and use the generic dApp icon for all the rest.

3. About the label my suggestion was to make an exception of the capitalized letters in this case and use dAPP instead of DAPP to emphasize it's a "decentralized app" (it's usually written in this way). However it won't be an issue to use DAPP if making an exception is a problem.

4. About Case 3 (Unknown URL) - we can have such a case. The wording of the warning text (in yellow) is synced with @smaroudasunicorn

5. About your suggestion to change the layout: @smaroudasunicorn if you think it's a better idea to use the suggested alternative layout (mockup provided by @peronczyk) I'll update the design accordingly. I was trying to utilize what we already have as visualization for transactions and smart contract calls.

[smaroudasunicorn]

I agree with Bart Comments

1. I agree to change the layout of dapp connection instead of using the transaction modal one. Maybe to combine the above approaches above (keep the arrow i.e.)
2. I agree about icons
3. If we change the layout this will be removed. Even with this layout propose to remove the dAPP box. I agree to remove also DAPP name box.
4. I think depends on the caller if i am not mistaken about the URL...
5. As mentioned in the one, we could keep the visualization with the arrow and have something combined from Bart's proposal @onvisions
6. Regarding account change, we can have it but i do not consider it as MVP and would like to avoid more time needed to deliver.

[peronczyk]

OK, so now I'm waiting for updated designs. Here's working POC of my changes: #3385