|
| 1 | +# Wallet Specification |
| 2 | + |
| 3 | +## UI/UX Requirements |
| 4 | + |
| 5 | +### The First Time |
| 6 | + |
| 7 | +The first time a user clicks on 'wallets' — first time means there was the orange indicator because they never attached any wallet —, a button is shown to start a **wizard**. The wizard can be skipped at any time in which case they will be redirected to "_Not the First Time_." |
| 8 | + |
| 9 | +_* maybe no button and immediately show wizard? *_ |
| 10 | + |
| 11 | +The wizard starts with a page where the user is asked to attach a receiving wallet (or skip). |
| 12 | + |
| 13 | +#### 1. Attach receive (or skip) |
| 14 | + |
| 15 | +The page shows a **table of wallets** that can receive. The table has following columns: |
| 16 | + |
| 17 | +- name |
| 18 | +- image |
| 19 | +- button to attach receive (**column is highlighted on this page**) |
| 20 | +- button to attach send (**column is muted on this page**) |
| 21 | +- popularity (how many stackers use this wallet to receive?) |
| 22 | +- self-custodial |
| 23 | +- KYC |
| 24 | +- Platform (iOS, Android, Windows, Linux, MacOS, Umbrel, Start9, Web) |
| 25 | + |
| 26 | +Boolean columns can have a checkbox as a filter. |
| 27 | + |
| 28 | +_* we might want to highlight some wallets based on popularity: "most stackers use this wallet to receive" *_ |
| 29 | + |
| 30 | +_* there might not be enough space on mobile for all columns / we need to find ways to save space, like via icons *_ |
| 31 | + |
| 32 | +_* 'attach send' button might need to be disabled on this page to not mess with flow? *_ |
| 33 | + |
| 34 | +The page also has a **search bar**. Users can enter wallet names and this will filter the name column. The search bar will try to **autocomplete wallets via dropdown** as the user types to prevent typos. |
| 35 | + |
| 36 | +Wallet examples: |
| 37 | + |
| 38 | +- CashApp |
| 39 | +- Strike |
| 40 | +- Wallet of Satoshi |
| 41 | +- Phoenix |
| 42 | +- Zeus |
| 43 | +- Alby Hub |
| 44 | +- Coinos |
| 45 | +- LND |
| 46 | +- Core Lightning |
| 47 | +- LNbits |
| 48 | +- Electrum |
| 49 | +- Cashu.me |
| 50 | +- Minibits |
| 51 | +- ... |
| 52 | + |
| 53 | +On selection, a wallet can have its own wizard that will guide the user through the process of attaching the wallet for receiving. |
| 54 | + |
| 55 | +If a wallet has no wizard, the user will only be shown input fields. |
| 56 | + |
| 57 | +Once a receiving wallet passed all tests (validation + network tests) and was successfully saved on the server or the step is skipped, the user is redirected to the next step: |
| 58 | + |
| 59 | +#### 2. Attach send (or skip) |
| 60 | + |
| 61 | +If the user attached a wallet during the previous step and it supports sending, we can ask them here if they want to continue configuring it for sending. |
| 62 | + |
| 63 | +Else — like in the previous step — this step shows a table of wallets that can send and a search bar. The only difference is that we highlight the column to attach send. |
| 64 | + |
| 65 | +Clicking on a wallet will start a wizard if available else the user will only be shown input fields. |
| 66 | + |
| 67 | +Once a sending wallet passed all tests (validation + network tests) and was successfully saved locally or the step is skipped, the user is redirected to the next step: |
| 68 | + |
| 69 | +#### 2.1 Wallet encryption |
| 70 | + |
| 71 | +This step only shows up if a sending wallet was attached. |
| 72 | + |
| 73 | +The step informs the user that the sending wallet is only stored on the device so they will not be able to use it on another device. |
| 74 | + |
| 75 | +If they want to use it on another device, they need to (a) write down the following 12 words and enter them into the other device or (b) manually configure the sending wallet on the other device again. |
| 76 | + |
| 77 | +If they choose (a), we will migrate the local wallet that was saved in the previous step to the server. |
| 78 | + |
| 79 | +After this step, the user is redirected to the next step: |
| 80 | + |
| 81 | +#### 3. Global wallet settings |
| 82 | + |
| 83 | +- configure dust limit |
| 84 | +- configure max fee for withdrawals (% and absolute amount, whatever is higher) |
| 85 | +- configure proxy for lightning address or not |
| 86 | + |
| 87 | +#### 3. Wallet badges |
| 88 | + |
| 89 | +Let them know that they now have a horse or gun so they know what it means when they see it next to the nym of other users. |
| 90 | + |
| 91 | +Also let them know that they now have a Stacker News lightning address. |
| 92 | + |
| 93 | +_* let users decide if they (additionally) want to show off which wallet they are using?? *_ |
| 94 | + |
| 95 | +#### Other considerations |
| 96 | + |
| 97 | +- users can leave wizard at any point in time |
| 98 | +- when they click on 'wallets' again, we will show them an option to continue where they left off or start new wizard |
| 99 | +- show wizard progress bar |
| 100 | +- when a wallet is attached, you can create another wallet of the same type via context menu |
| 101 | + |
| 102 | +_* starting a new wizard: what to do with any existing data on device or server? *_ |
| 103 | + |
| 104 | +_* separate forms to save receive and send: (how to) share common fields like URL for LNbits? *_ |
| 105 | + |
| 106 | +### Not the First Time |
| 107 | + |
| 108 | +Show table of wallets with buttons to attach send or receive + search bar. |
| 109 | + |
| 110 | +If wallet encryption was enabled, we can show them which send wallets they have on the server but can't decrypt currently (lock symbol). |
| 111 | + |
| 112 | +If wallet encryption was not enabled, give them the option to enable it. |
| 113 | + |
| 114 | +## Technical Requirements |
| 115 | + |
| 116 | +- we can fetch all wallets at once on page load |
| 117 | +- if wallet encryption is enabled, we sync wallet updates and deletes between devices ASAP |
| 118 | + - don't poll for wallets but poll for wallet updates via timestamp column for last update of wallets |
| 119 | + - reload wallets on change |
| 120 | +- users can only save individual wallets, and only save or receive, not both at the same time |
| 121 | + |
| 122 | +### implementation details |
| 123 | + |
| 124 | +- replace generic, "obfuscated" code for mutations, typedefs etc. with code generated during build time |
| 125 | + - easy to read and reason about |
| 126 | + - DX needs to be considered |
| 127 | +- abstract away that send wallets can be stored locally or on server via custom GraphQL scalar serialization and local fields |
| 128 | + - we can use `useQuery` to fetch wallets as if everything about wallets is always stored on the server |
| 129 | + - we can use `useMutation` to store wallets as if everything about wallets is always stored on the server |
| 130 | + - encryption of send wallets must be handled in GraphQL layer somehow |
| 131 | + - was thinking about serialization of custom [scalars](https://graphql.org/learn/schema/#scalar-types) ... but they run on the server, not on the client |
| 132 | + - make sure this ACTUALLY works 100% and would NEVER send unencrypted values to the server |
0 commit comments