search

Magickbase / neuron-public-issues

Neuron Issues
6 stars 3 forks source link

Advance mode on sending transactions #56

Open Keith-CY opened 2 years ago

Keith-CY commented 2 years ago
Keith-CY commented 1 year ago

Chained transactions can be supported by introducing Lumos.

I remember that @homura had also suggested this feature, whether a draft could be provided to help the @Danie0918 and @Sven-TBD to understand chained transactions on CKB. So they can design the UX for this feature.

Keith-CY commented 1 year ago

In recent discussions about WalletConnect UX, we mentioned that users may wish to retain certain special cells to prevent them from being used in constructing transactions.

We can consider this feature on Neuron, the desktop wallet, first.

BTW, lock a cell and allow user to consume cells which hold data can be done together by setting cells holding data locked by default

homura commented 1 year ago

description and use case for chained transaction: https://talk.nervos.org/t/non-blocking-chained-transaction-and-its-applications-in-ckb/6649

homura commented 1 year ago

I'd recommend taking a look at the design of the Sparrow Wallet which is the most customizable Bitcoin wallet I have ever tried

Keith-CY commented 1 year ago

I'd recommend taking a look at the design of the Sparrow Wallet which is the most customizable Bitcoin wallet I have ever tried

cc @Danie0918 @Sven-TBD

Danie0918 commented 1 year ago

As far as I understand, chained transactions refer to a block in CKB that packs multiple transactions in which the transactions have interdependent relationships, and it is achieved by pre-constructing chained transactions and then submitting them to the chain. Regarding here in Neuron wallet, we have more technical improvements, I don't have any specific functional changes in mind for the example in the documentation, can you provide an example to help me understand?

Also about the function of locking cells, I imagine we can provide a page to manage the live cells under the wallet, here we provide the cell of all wallets or the cell management of individual wallets, any idea here? @Keith-CY @homura

Keith-CY commented 1 year ago

As far as I understand, chained transactions refer to a block in CKB that packs multiple transactions in which the transactions have interdependent relationships, and it is achieved by pre-constructing chained transactions and then submitting them to the chain. Regarding here in Neuron wallet, we have more technical improvements, I don't have any specific functional changes in mind for the example in the documentation, can you provide an example to help me understand?

The functionality has been implemented in lumos, which is being integrated into neuron. The main improvement may be UX, e.g.

  1. visualize chained transactions together
  2. prompt queued transactions to be chained
  3. inform users that transactions will be submitted in next x seconds if chained
  4. inform users when a transaction is removed from the transaction chain

The UX could be similar to queued merges in GitHub

image image image image

Also about the function of locking cells, I imagine we can provide a page to manage the live cells under the wallet, here we provide the cell of all wallets or the cell management of individual wallets, any idea here? @Keith-CY @homura

As mentioned in downplaying address, it's hard to synchronize all wallets in the light client mode, so listing cells of all wallets is infeasible.

Danie0918 commented 1 year ago

This requirement I plan to implement by adding a preview popup for sending transactions and adding an management page for cells.

【Preview sending transaction pop-ups】This will contain basic information about the build transaction and visual charts to help users understand the upcoming transaction submission and customize its settings in subsequent iterations.

  1. The transaction preview pop-up appears after the user clicks send on the send page.
  2. Preview information includes transaction hash, transaction information, transaction topology and operation area.
    • Transaction hash：Display full transaction hash and support replication
    • Transaction information:Display amount, fee, size and cyclesdata,no interaction.
    • Transaction topology：Includes transaction inputs and outputs,need to display the type and amount and support floating layers to display the full address.
    • Operation area:Confirmation and submission of transactions.
  3. Users need to be alerted when a transaction has been chained-up or removed.

transaction

【Cell Management】This page will display all live cells and allows users to manage them.

  1. The entry will be placed next to the balance under the overview page, where the balance still shows the full balance and needs to be prompted when there is a locked balance, click to view to enter the cell management page.
  2. The Cell Management page displays the number and list of live cells and allows for the management of these cells. -List Title：Display date, type, amount and status and support sorting. -Operation:Support view details, open in browser, lock/unlock and spend. -Batch operation：The user can select the cells to be manipulated by clicking on the entry or select all cells for batch manipulation.
  3. Locking or unlocking the cell requires verification of the wallet password.
  4. The spend cell will jump to the send page and bring in the full amount (including fees).

cell_management

@Keith-CY @homura Any suggestions for the above?

Keith-CY commented 1 year ago

This requirement I plan to implement by adding a preview popup for sending transactions and adding an management page for cells.

【Preview sending transaction pop-ups】This will contain basic information about the build transaction and visual charts to help users understand the upcoming transaction submission and customize its settings in subsequent iterations.

  1. The transaction preview pop-up appears after the user clicks send on the send page.

  2. Preview information includes transaction hash, transaction information, transaction topology and operation area.

    • Transaction hash：Display full transaction hash and support replication
    • Transaction information:Display amount, fee, size and cyclesdata,no interaction.
    • Transaction topology：Includes transaction inputs and outputs,need to display the type and amount and support floating layers to display the full address.
    • Operation area:Confirmation and submission of transactions.
  3. Users need to be alerted when a transaction has been chained-up or removed.

transaction

【Cell Management】This page will display all live cells and allows users to manage them.

  1. The entry will be placed next to the balance under the overview page, where the balance still shows the full balance and needs to be prompted when there is a locked balance, click to view to enter the cell management page.
  2. The Cell Management page displays the number and list of live cells and allows for the management of these cells. -List Title：Display date, type, amount and status and support sorting. -Operation:Support view details, open in browser, lock/unlock and spend. -Batch operation：The user can select the cells to be manipulated by clicking on the entry or select all cells for batch manipulation.
  3. Locking or unlocking the cell requires verification of the wallet password.
  4. The spend cell will jump to the send page and bring in the full amount (including fees).

cell_management

@Keith-CY @homura Any suggestions for the above?

I've divided these two designs into

So the discussion could be clear