SH Chat Login

[smaroudasunicorn]

Goal is to be able to Register and Login in SH Chat through SH Wallet.

Flows description
https://aeternity-blockchain.atlassian.net/wiki/spaces/CBFD/pages/449085490/Referral+Program+flows

HL Design Approach
https://aeternity-blockchain.atlassian.net/wiki/spaces/CBFD/pages/459079702/Referral+Program+Flows+High+Level+Design

We would like to provide an endpoint in the SH Wallet that can be called by SH Chat and provides a JWT token (check comment for POC)

[smaroudasunicorn]

I would like to share a sample made from philip for JWT generation.

https://github.com/thepiwo/test-jwt-auth/blob/main/test/exampleTest.js

This POC emulates the key derivation of superhero wallet, generate a jwt token with the first account

@CedrikNikita kindly check

[smaroudasunicorn]

Following discussions with @paolomolo @CedrikNikita @thepiwo I would like to request from @onvisions your help.

Login

SH Chat will call SH Wallet to sign a provided Message. Type of the message will be JWT. User signs the message and returns the result.

Registration
Upon SH Chat Registration User will be asked to sign a Transaction. In this transaction it is proposed to be remarked to the user that Upon signing the transaction he will initiate a new transaction to the caller. We will need to notify the user that SH Wallet will modify the object to reflect the caller. Highlight that chat is not aware of your address (display the caller).

[thepiwo]

I'd propose to rather clearly define the design goals, instead of the abstract process.

As far as I understood @CedrikNikita we need:

• decision on when to ask for permission
• design for jwt signature popup (see already developed example for added type field)
• design for notice to user that caller in transaction signature popup is changed

Aeternity signed message example:

JWT signed message example:

[onvisions]

@smaroudasunicorn @thepiwo Please review suggested design and let me know if it works or I have to apply further changes.

1. The design below suggests that we have a general template for similar cases with third party dapps and a customized version when the dapp is ours (like Superhero Chat, DEX etc).

In case it's our trusted dapp:

• hide the warning: "Confirm the transaction only if you trust the dapp and its owner.";
• explain the user what exactly is happening when confirming the transaction/signing the message like: "... in order to register" / "...in order to login". See suggested design mockups below.

2. Button labels for all confirm/sign modals:

• When confirming a transaction the button labels are: "Reject", "Confirm";
• When signing a message the button labels are: "Cancel", "Sign".

Design:

1. Confirm transaction

Superhero chat (Register account):

Third party dapp:

............................

2. Sign message

Superhero chat (Login):

Third party dapp:

copy message feature:

sign_message.mp4

[thepiwo]

I think for sign transaction where the caller is replaced should be more obv. in the design. A technical question would be, how to differentiate "trusted dapps" @CedrikNikita

[onvisions]

@smaroudasunicorn , @CedrikNikita , @thepiwo

I think for sign transaction where the caller is replaced should be more obv. in the design. A technical question would be, how to differentiate "trusted dapps" @CedrikNikita

May be we can just use the warning color to emphasize this:

The problem is from average user perspective this "the caller has been replaced" creates unnecessary technical complexity. It was hard to me to understand what's exactly happening on tech side. But as a user a care only about what I'm signing or approving explained with human friendly words such as:
"confirm the transaction to register your account" or "sign the message to login". IMO all technical complexity should be included in "Advanced transaction details" section.

[thepiwo]

@onvisions looks good to me!

[onvisions]

@CedrikNikita

1. I am suggesting to add more description and technical details about the replaced smart contract caller within Advanced transaction details block. We can sync the exact wording when you come to the implementation of this template.
2. I will also modify the rest of the templates with warning color in the following part:
   "Sign the message/Confirm the transaction only if you trust the dapp and its owner."
3. IMO keeping a list of trusted dapps (like Superhero DEX and Superhero Chat) can lead to better UX because it will allow us to display customized wording as we know what the transaction is about (e.g. Login, Register account etc.) or not display some warnings like the one stated above. In case keeping such a list will be an overkill I'd suggest to better define the functions names of our dapps with human readable text such as "register_account".

But even better if we can display:

Superhero Chat
https://chat.superhero.com would like you to confirm a transaction in order to register account.

Superhero Chat
https://chat.superhero.com would like you to sign a message in order to login.

[onvisions]

1. Sign message:

2. Confirm Transaction:

Superhero Chat:

Third party dapp:

[smaroudasunicorn]

I am ok

[CedrikNikita]

fixed by #2899,
fixed by #2952

Visual improvements of other modals will be a separate task.