• - New Account/Wallet
• - Import Metamask
• - Hardware Wallet

• - Revise design based on User Testing

• Top Menu
• Address total + buttons
• Assets/Activity
• Bottom menu

Two actions to be had here:

• Linting (using run-p?).
  • eslint for JS, using eslint-config-prettier, airbnb linting rules, and TypeScript extensions to those rules.
  • prettier for config and docs (yaml, json, toml though we don't really have any, and markdown)
  • fix all linting errors
• Basic smoke test extension build. The goal here isn't to pump out artifacts yet necessarily, but to have something that will fail if we break the build somehow.

• Switch between networks page

• Activity
• Governance

An empty account history sucks, and it makes migrating wallets or even browsers pretty inconvenient.

A combination of the Alchemy Transfers and Token APIs should do the trick.

• Pull data in the backend (#126)
• Reconstruct the account history for the API
• Display past transactions + any token balances

• web3-react
• web3-modal
• WalletConnect
• Onboard.js

match illustration style for headers in UI

• Farming
• Single Farm
• Pools
• Single Pool
• Withdraw farm + pool
• Deposit farm + pool

There are a few options to improve gas estimation. Two worth exploring are

• GasNow
• BlockNative

Not sure this is the "right" way to handle L2s going forward — in fact, quite the opposite. But if it gets traction supporting it is simple

https://news.coingenius.ai/consensys-debuts-metamask-custom-networks-for-layer-2/

Optimize for:

• Chrome
• Brave
• Firefox
• Safari

Would be interesting to use HashMasks, CryptoPunks, and ENS names to start

• Change Wallet
• Card Menu

We want browser push notifications on

• Tx submission
• Tx mempool drop
• Tx confirmation
• Payment receipt

To avoid running a centralized backend, we want to use a provider that supports WebSockets.

https://docs.blocknative.com/websocket

We also need to fall back gracefully, first to a regular data provider or local node, then to skipping the functionality.

Since extensions are loaded locally rather than requiring network round-trips and bandwidth, I haven't been able to find strong evidence either way on whether bundling and minification provide a significant runtime impact. The downloaded extension itself is gzipped, so a lot of the file size improvement of minification most likely already comes from that compression process.

The goal here is to understand:

• What the loading performance impact is of unminified code.
• What the loading performance impact is of unbundled code.
• What the loading performance impact is of bundled source maps, and whether browsers pick these up easily.
• What the extension size impact is of unminified code.
• What the extension size impact is of unbundled code.
• What the extension size impact is of bundled source maps.

These can then be synthesized with any other concerns to make a decision about the best way to move forward on minification and bundling.

But Why?

One of the most developer-hostile things modern web technology does is obfuscate code. Source maps help, but require additional work and are often not included in production bundles. Tally being an open source project, we should encourage exploration and tinkering with the underlying source---the easiest way to do that is to give users and developers an already-usable code base with the shipped extension.

• Include Arbitrum in the default network selection dropdown
  • Refactor ChainService to work with Alchemy + Arbitrum
  • Refactor IndexingService to work with Alchemy + Arbitrum
  • Include Arbitrum on Kovan
• Include Arbitrum-specific token lists
• Recognize Arbitrum bridge transactions in wallet activities
• Recognize Arbitrum bridge transactions when signing
• Support 0x on Arbitrum mainnet and Kovan
• Include a "send to Arbitrum" on Ethereum mainnet and Kovan that uses the Arbitrum bridge

Developing fast means we need a simple way to upgrade user state every new extension version. How do we handle state schema changes?

The entire legacy keyring deserves a rethink, but starting with fixing this inconvenience for DeFi prosumers and developers would go a long way.

Build system dev:

• build for chrome
• live reload

Build system production:

• safari
• chrome
• firefox

Docs:

• have a loose chart of expected flows and communications
• doc project layout

Testing:

• setup testing
• e2e in browser (work with FED)
• unit
• component testing (work with FED)

github actions:

• prepare prod builds on release branches?

This is a big one.

A UTXO model breaks many assumptions in wallet land, including the idea of watching accounts for updates. There are a few major requirements

• A web3-style API for Bitcoin
• PSBT support, allowing more complex tx construction
• Message signing support
• More flexible chain data models to allow tracking single addresses (boo) or x/y/zpubs (yay)

Create Build System

needs:

• build system should create a directory at the root of the project called dist
• dist should contain the different build directories per browser platform
• each one containing a manifest extended from _base.json with the particular platform specific manifest
• each one should have this tree: (chrome reload should only be in dev mode. Exclude it from prod)

chrome
   ├── background.js
   ├── chromereload.js
   ├── content-script.js
   ├── inpage.js
   ├── manifest.json
   ├── public
   │   └── popup.html
   └── ui.js

popup could be moved to the dir root, manifest:_base would need to be changed to reflect this public is all static files images etc.

DEV MODE:

• yarn start should do dev mode
• dev mode should allow for global process.env.NODE_ENV which should be 'development' or 'production' or 'test' (for now lets not worry to much on test mode extension test can get complicated and might require a special build process)
• live reload yasss including chromereload

PROD:

• exclude chromereload.js from manifest
• zip each browser directory for publish

Up for negotiation:

• separate dependencies into their own script from ui.js and background.js so scripts can be loaded faster this seen in mekamittens as bg-libs and ui-libs

currently the branch build has this functionality but needs to be cleaned up sense it was literally taken from mekamittens and paths were changed and some unnecessary code was deleted

Safari now support Web Extensions! Unfortunately, hardware wallet support will require some additional, perhaps native, work.

• Get the extension building for Safari
• Publish a dev build Safari users can install manually
• Package up a Safari extension for the app store (confirm licensing will work)

• Include Optimism in the default network selection dropdown
• Include Optimism on Kovan
• Support Uniswap, Saddle, and Synthetix on Optimism mainnet
• Include a "send to Optimism" on Ethereum mainnet and Kovan

We need separate builds for

• Chrome
• Firefox
• Brave
• Opera

Tally can hijack MetaMask connections and act as the primary wallet, similar to NiftyWallet.

Some users might prefer that behavior, for others it's an inconvenience. Making it a configurable default is 👌

What interface do dApps see when a user has Tally installed?

We need to

• Include a Web3 provider
• Support account unlocking
• Consider not showing the in-page JS unless a user has decided to connect to a wallet (preventing the easy Ethereum user tracking MetaMask et al currently enable)

This might have to happen via the usual inpage.js, or via content scripts for manifest v3 forward compatibility.

Relates to #4