Is your feature request related to a problem? Please describe.
Currently, in our wallet, if a user wants to tweak the gas setting they are asked to enter the gas amount X and the gas price Y. Then gas fee = X * Y. (The reason for that is that the API requests these 2 values)

However, as a user it is quite confusing to know what value to input in these fields.

Describe the solution you'd like
On ETH (specifically metamask), users are asked to set the gas price and are shown the corresponding gas fee (or vice versa). The gas amount is estimated. After confirming with @polarker, this is something we can also do for Alephium in order to improve the user experience.

Additional context
Adding Metamask screenshots

• Simplify transaction gas settings on desktop wallet
• Introduce simple gas settings on mobile wallet

In order to increase security and do better than most crypto wallets, in case of a change in on-device biometric settings :

1. Let's deactivate biometric authentication;
2. Fallback to pin and show a popup asking the user to reactivate the biometric option if needed.

I personally like the wording used by Authy:

We are very lucky to recently have received an influx of contributors who are willing to translate our project!

This poses some new problems:

1. Our translators are not familiar with git and GitHub workflows (PRs, reviews, branches, rebase, merge)
2. Our translation files are stored in JSON format. Our translators are not familiar with JSON and might create a PR with a corrupted structure.
3. Providing translations requires apart from creating a JSON translation file to also update pieces of code to pick up this new file and enable the translation.

Maybe it's a good time to look into translation management tools.

Some initial research:

• https://locize.com/ (free for open-source projects - need to verify eligibility, found through the https://react.i18next.com/ docs, provides awesome integration with our tooling, but I don't like that the content is managed in their servers and not on GitHub)
• https://www.transifex.com/ (free for open-source projects - need to verify eligibility. This tool is used by the open-source project I was working on while at CERN, check out their contribution guide)

My personal requirements would be:

• Minimise time required by devs to integrate new language
• Minimise time required by devs to register new translation strings when developing new UIs (currently, every time there's a new string, the dev needs to create a key-value pair in EVERY translation JSON file, which is cumbersome)
• Provide UX friendly tool for translator who is unfamiliar with git(hub)
• Allow for review workflows
• Host translations on GitHub

WDYT?

Cancelling a FaceID (or fingerprint ID for that matter) authentication makes the app try again by re-prompting the authentication UI.

Cancelling a biometric auth should probably prompt the pin screen.

The community would love to see support for Touch ID on the Desktop Wallet, for devices like the Macbook Pro that have it supported. Secure, fast, and ultra, ultra-convenient.

As discussed in the meeting in Paris, the node provides an endpoint that returns its version. We could query this endpoint to inform the user whether their wallet is compatible with the node or not and whether they need to upgrade.

Similar to the tooltip we show when adding the 0.001 ALPH storage rent, we should add a little explanation next to the amount shown when interaction with a contract.

The path can be added under the address hashes in the address list used for keys export:

The POST /transactions/sweep-address/build endpoint will sweep all ALPH as well as all tokens from one address to another.

It is probable that when the user clicks "Max amount" when sending ALPH, they actually want to sweep. However, if they don't also select "Max amount" for all the tokens of the address, the sweep endpoint will not be called, but the regular one POST /transactions/build. This will result in an error:

Not enough balance for fee, maybe transfer a smaller amount

I propose that when the user clicks "Max amount" when sending ALPH, the UI should ask them "Do you want to also move all tokens from this address"?

@mvaivre opinions?

react-scrollbars-custom is not compatible with React 18. We heavily depend on this library. Thus, even though we have upgraded React to v18, we are still using the React v17 API. Once this lib becomes compatible, we can switch to the React 18 API by simply using the render method of createRoot instead of ReactDom: https://reactjs.org/blog/2022/03/08/react-18-upgrade-guide.html

I've opened an issue on the library (even though a similar one existed already:

• xobotyi/react-scrollbars-custom#343
• xobotyi/react-scrollbars-custom#234

I thought of using react-custom-scrollbars-2 but it's written in JS (no types available).

• #245
• #246
• #247

We could fetch the release notes from Github and display them in the "Upgrade available" popup in the app.
This would give us the opportunity to properly communicate important info.

Designs available on Figma :

(note - test wallet so ignore the seeds:) nothing there)

Right now the wallet creation requires putting all seed words back in order.. I've seen other wallets that just say enter seed alephium/desktop-wallet#4, seed alephium/desktop-wallet#5, seed alephium/desktop-wallet#10, etc.. (basically spot-checking) - a more lazy way to do this.. Might be nice to not ask for all words to be populated in order?

when the transaction has been sent, if the recipient address isn't in the contact list, we could display a popup saying "Would you create a contact for {addressHash}?", with a little paragraph explaining why it can be useful.
This popup could be dismissed and the user could choose not to show it anymore.

mentioned in alephium/desktop-wallet#523 (comment)

At the moment we disable the back button to avoid changing the bytecode or addresses. In the future we should only enable gas settings editting.

• #282
• #281

alephium/desktop-wallet#515 (comment)

See https://github.com/alephium/mobile-wallet/pull/95/files#r1016480952

• Define requirements
• Research on push notifications with Expo

Why? => Having the whole app opening when a user wants to sign something isn't really needed. We could be more subtle by showing only some kind of notification popup with only the necessary content :

1. Unlock a wallet if needed
2. See what should be signed. What would be the outcome.
3. Button to execute the action.
4. Feedback (validated or error)

This would really make the desktop app a versatile tool to interact with dApps.

We are getting this warning:

sign_and_release (macos-latest)  
Node.js 12 actions are deprecated. Please update the following actions to use Node.js 16:  
samuelmeuli/action-electron-builder@v1. For more information see:   
https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/.

GitHub will deprecate Node.js 12 on September 27th.

https://github.com/alephium/desktop-wallet/actions/runs/4798619034

• Clarify if we want to support "fractional NFTs" (which is seems kinda counter-intuitive :)).
• Depending on the answer, let's simplify the flow for sending NFTs, by removing the "amount" part of the process.

It only happens in a corner case where someone JUST funded one of their addresses and tries to send an amount from this address that is higher than the amount the address had before the last funding.

Describe the bug
In my local devnet (node 1.3.2, expl-bck 1.6.0) I noticed that after I send a tx from address X to another Y and
once the explorer API getAddressesAddressTransactions endpoint (get confirmed txs) as well as the getAddressesAddress (get address details) include this tx, then I have an issue building a new transaction from address Y, unless I wait for a minute or so. It seems that the node is not up to date with the latest tx. It returns an error of “insufficient funds”. Then, after a few seconds/minutes, it stops returning this error.

To Reproduce
Steps to reproduce the behavior:

Expected behavior
Be able to send the funds once a confirmed tx is received

Additional context
It appears that we wait for toGroupConfirmations >= 1 to be able to make a transaction from Y. This number is from /transactions/status:

{
  "type": "Confirmed",
  "blockHash": "bdaf9dc514ce7d34b6474b8ca10a3dfb93ba997cb9d5ff1ea724ebe2af48abe5",
  "txIndex": 0,
  "chainConfirmations": 1,
  "fromGroupConfirmations": 2,
  "toGroupConfirmations": 3
}

If Y has funds in the wallet, Y could use the existing UTXOs to build transactions.
If Y is a new address, it will need to wait a bit more. For now, we could probably mark the tx as pending if toGroupConfirmations < 1

Related issue: alephium/explorer-backend#198

Cf. alephium/explorer-backend#465

Is your feature request related to a problem? Please describe.
I am having a hard time to calculate when the next unlocking date will be and how many coins will be unlocked.

Describe the solution you'd like
It would be useful to know when the next unlocking will take place and how many coins will be unlocked (as well as any future unlockings).

Describe alternatives you've considered
The current desktop wallet indicates the amount of available and locked balance.. Going through the transactions list I can find transactions that have locked UTXOs, but it is not very user-friendly when one is looking for an overview.

Additional context
I think this would be useful information to put somewhere in the overview. Maybe a small text under the locked amount that says "next unlock of X coins on DATE" with a link to see more unlock dates, either on a tooltip or a modal, or page.

Hardware wallet support is a must-have.
As discussed, let's start by investigating adding support for Ledger Nanos which are extremely popular (easy to get, relatively cheap, dev-friendly etc.).

This issue can be used to document the investigation progress, but let's try not to spam it too much ;)
Once concrete tasks can be formulated, let's link them here to reflect ongoing progress.

Here is a draft proposal. We could add the support in two phases:

Phase 1:

• Desktop wallet exports public keys of addresses (so need a button to export public key)
• Full node builds unsigned multi-sig transactions
• Signers sign the tx using desktop wallet (so need a new TxModal for signing unsigned transactions)

Phase 2 (Optional as it might complicate the UI):

• Desktop wallet builds multi-sig transactions directly

Describe the bug
@nit27 just found an issue when the desktop app runs ‘auto update’. It showed that the dowloaded calculating percentage somehow went incorrectly.

Expected behavior
percentage display should be consistent

Screenshots

Environment

• Internet connection is fine.
• MacOS 13.2.1

Additional context

• issue happened auto update from v1.5.2 to v1.5.3

When clicking "Connect with desktop wallet" in the DEX, we get the following window that says "open xdg-open" instaed of "Alephium". Also, clicking it doesn't open the wallet.

@Lbqds reported that the only way to make it work was:

1. Create a file called alephium-wallet.desktop
2. Input the following contents:

[Desktop Entry]
Name=Alephium-Wallet
Exec=/home/lbqds/Desktop/Alephium-2.0.0-rc.40.AppImage
Icon=/home/lbqds/Desktop/icon.png
Type=Application
MimeType=x-scheme-handler/alephium;text/html;

you need to replace the Exec and Icon with your path.
3. Make this file executable: chmod u+x alephium-wallet.desktop
4. Move alephium-wallet.desktop to ~/.local/share/applications

Proposed by @polarker in https://github.com/alephium/js-sdk/pull/133#issuecomment-1328787203, we should replace our current encrypt/decrypt functions of lib/password-crypto.ts with a mature library like @metamask/browser-passworder: https://www.npmjs.com/package/@metamask/browser-passworder.

We need to investigate a few things:

1. This library is meant to be used by browsers because it relies on the global.crypto browser API. This means it wouldn't work for nodeJS applications. So, if we want our SDK to be usable by nodeJS apps, we need to use a different library, or polyfill that one. But polyfills usually work the other way around, nodeJS -> browser, not browser -> nodeJS. To be investigated. Not relevant anymore, we don't need Node.js support for our monorepo shared packages.
2. Does Metamask provide a different way of encrypting/decrypting for nodeJS apps? Same as above
3. Find out what polyfills are needed to make this work in RN (mobile wallet) and how Metamask does it.

We currently have 2 features that (potentially) require the knowledge of the whole transaction history for all addresses of the wallet in order to work correctly. Those are:

1. Historical data on price: alephium/desktop-wallet#587
2. Future unlock schedule: #44

Wouldn't it make sense that the wallet stores locally in an encrypted file(s) all address transaction data that has been recorded on the blockchain and there is no way it gets changed?

Ideas:

• Only store transactions that have X confirmation (or are older than 24h or sth)
• On wallet start-up, fetch all new transactions and update store

Benefits:

• Fewer requests to the explorer backend service
• Better UX since transaction pagination will not need to reach to a server (we could implement infinite scrolling)
• Can implement feature 1
• Can implement feature 2

@mvaivre, @tdroxler, what are your thoughts on this?

Some quick math: An average tx with 2 inputs, 4 outputs, some ALPH and some tokens takes about ~2'500 characters (with a simple compression it can get down to 1'200 characters) so that's about 1KB per tx.

Open questions:

• How many txs does the larger ever Alephium wallet has?
• Is the performance of the electon app get affected when the Redux state grows a lot? (this is not inherently a potential problem of this proposal, a user can already click "See more" as many times as they want to load all their history)
• What other alternative proposals are there for implementing feature 1 and 2?

Inspired by Revolut implementation.

Maybe SectionList can come to the rescue here: https://reactnative.dev/docs/sectionlist

Allow users to order addresses by:

• Last use (default)
• Worth (desc)
• Alphabetical (desc)

Use a Select component. Choice should be persisted between session, ideally per wallet.
Other options like this one will certainly pop up in the future.

Option popup to be designed.

Having a responsive (maybe simplified) layout could be really useful when the wallet needs to be used alongside dApps (ie. in split mode). We need to define if / what parts of the UI should be simplified / hidden when the width is restricted.

Add small explanation box in all areas where users expect certain features to be available saying that they are not in passphrase-enabled wallets.

Let the user send to multiple recipients in one TX.

@polarker 's opinion on this topic:

All recipient must be in the same target group. We could prepare multiple transactions for one user action, for better user experience. I will need to improve the SDK first to support this better.

Current concept:

TODO :

• Design
• Adapt the SDK to "batch" multiple TXs in on user action

when sending to someone, i’d like to be able to start typing their name (for now I HAVE to type on the little icon to make the adress book appear)

Assuming there are 2 releases on GitHub, set as the following:

• 1.5.0 (marked as latest)
• 1.5.0-rc.0 (marked as a pre-release)

The 1.5.0-rc0 wallet will check if there are new releases when launched. Unfortunately, the following code returns 1.5.0-rc.0 instead of 1.5.0, so the update system does not work if the currently installed version is an RC.

const version = await electron?.updater.checkForUpdates()

We don't expect users to install RC versions, however, so I wouldn't consider it a big problem. Something to look into it, however.

Let's get rid of this awful library.

As @MaudSimon mentioned in alephium/desktop-wallet#557 (comment), users are requesting the ability to change their password. Currently, the only way to do that is:

1. Import the mnemonic to a new wallet
2. Delete old wallet

TBD

The function deriveNewAddressData is returning an AddressKeyPair

export type AddressKeyPair = {
  hash: string
  index: number
  publicKey: string
  privateKey: string
}

Having the private key in here could cause security issues (like storing it in clear text by mistake along with non critical data).

Cheng is suggesting that we could refactor the function so that we have a specialized function for returning the private keys, and another function for returning non-critical data like address, public key, group etc.