Link shortning

[AliMeer]

A service:

• Link to retrieve data/ long link
• Should work in-app browser and web browser
• Ideally should have its own server and not on BH server
• Customise link with domain name and type of data
• We can use it for Donation WebView as well R&D
• Can the code for the data be used without the bitly link
• Solution should not include tracking information

Description:

This issue talks about the changes to the link that is sent out but also has an impact on the QR code as a similar function and introduces request code.

Trigger: The user decides to send a Hexa request to someone else. (Note this is now only for Keeper and F&F request but may be extended to other request types in the future)

Precondition: The app is online and connected to the relay.

Flow:

1. User initiates Add a Keeper or F&F which produces a request like in the current flow. Here the 2nd factor method is added based on Lin5.
2. The requesting app stores all the relevant but not sensitive data on the backend and receives a request code as a response to it. The data stored is described in Lin 4
3. This request code can be communicated to the receiver in three ways: QR, Code Copy or a deeplink:"Hexwallet.io/request/<code."
4. QR and DeepLink UX will be like it is currently and the QR does not need a 2nd Factor. For code copy, the user can copy the code from the share-link modal. On the receiving side, the universal scanner on the Home Screen will also have a field "Enter a bitcoin address or a Hexa Request Code"
5. All these three mechanisms lead to the same next step where validations happen based on the initial data on the relay. (validations covered in Lin 4)
6. This data is expired after the time and any request accessed after the expiry can prompt that the request is now expired
7. It currently takes a considerable amount of time for the link to be generated, this needs to be looked at if possible.

Dependencies:

1. Lin4, Lin5

Exception flows:

1. The re-share and change contact/ device etc. work exactly like they work currently. Only difference being the link is very short and the data used for validation is not on the link but in the initial data store.
2. For the staging or dev app, the link can differ as hexawallet.io/drequest/ or hexawallet.io/srequest/

Lin4: Initial Validations:

Description:

This issue talks about the changes to the link that is sent out but also has an impact on the QR code as a similar function and introduces request code.

Trigger: The receiver clicks on a Deeplink request or enters a Request Code or scans a QR

Precondition: The requester has generated the request (Lin3) and send it to the receiver

Flow:

1. The requester stores the following in the Initial Request Data (but not limited to): Request Type, Requester App Version, Wallet ID, expiry time (UTC), 2nd factor type used(email, phone, OTP, none), partial details of the 2nd factor like some letters of the email or digits of the phone number, screen name of the requester, more:
2. Some of this data is encrypted with the 2nd factor if used: Wallet ID, permanent channel encryption key
3. The expiry time in UTC enables the logic of the expiry to be decided on the requesting app.
4. If current UTC>expiry UTC, then the request has expired and relevant message is displayed
5. If Requester AV > Receiver AV, then version check component is used to decide if the version can talk or the receiver needs to upgrade to do this and relevant message is displayed
6. If Requester AV <= Receiver AV, the logic of handling the request is in the new receiver app and the processing progresses.
7. If this goes through, the user enters the complete information of the 2nd factor by looking at the partial information and the type.
8. If decryption fails using the 2nd factor then the request is not accepted and the message is displayed
9. On decrypting the Wallet ID is checked against the existing Wallet IDs in the F&F list. If the wallet ID exists for the same request type then the message is displayed that the contact exists.
10. If the wallet ID exists but for a different request type e.g. Keeper request for a F&F, then it is a valid request and the processing happens.
11. The rest of the processing is as is and this is only about accessing and validating the request.

Lin5: Optional 2nd factor

Description:

This issue talks about the changes to the link that is sent out but also has an impact on the QR code as a similar function and introduces request code.

Trigger: The requester wants to send a request to the receiver

Precondition: Initial data is gathered on the app and associate a contact step is done

Flow:

1. When using the link or Request Code, the user is given an option to add security to the request by adding a 2nd Factor with a checkbox. The text will be: Add 2nd factor: Check here for letting the user enter their phone number xyz before they can accept the request. Check here for letting the user enter their email address xyz before they can accept the request. Check here for letting the user enter OTP: xyz before they can accept the request. The request expires in n hours. '2. If the user selects it, some of the data stored is encrypted (Lin4) but the link does not have to change as it can be the same code. The user enters the 2nd factor only depending on the data value of 2nd factor type '3. In case of QR, the 2nd factor is always included in the QR even if the user does not choose it as the phone number/ email/ OTP is also sent in the QR. And the only difference is that the data is decrypted using the 2nd factor or the 2nd factor is ignored completely '4. If the user tries 're-sharing' the 2nd factor selection cannot be changed and is greyed out.

[antuz123]

@AliMeer - All the ones I found have different descriptions and properties. Looking at the options, the properties we need are:

1. Ideally should have its own server and not on BH server. Thee free tools seem to need you to install the code on your own server.
2. Should have API, some are manual shortening
3. All do not mention deeplink. BitLy does, but since we are having a redirect anyway do we want them to support deeplink?
4. Sniply - has 'CTA', not sure what that means. May be of help may be a problem.
5. None were explicit if the app can call them directly to shorten the link. This is a bit different in our case as in most other cases, the server would be doing this piece with an API key or something. We may not be able to put the API key on the app as it is open source.

Best to do a quick POC with a few to check once thee above is considered.

[AliMeer]

We can pick this up after the links start getting generated during sharing.

[cakesoft-shashank]

For the links, we should shorten any link we are generating from the app, deep link or not:

• F&F request - request.hexawallet.io/code
• Keeper request - request.hexawallet.io/code
• Hexa gift - gift.hexawallet.io/code
• Donation weblink - donation.hexawallet.io/code

[cakesoft-shashank]

Configuration dns with hexawallet.io is remaining

[cakesoft-swati]

• Closing this issue as discussed with dev.