Gaba MM extension.md

Gaba <-> MM extension

tldr

• main concerns: provider/network controller
• will have to fill gaps within the mm controller
• lots of work for unclearish benefits (collectibles can be done in the extension w/out gaba, same with incoming txs), doesn't really get us onto one code-base, just gets some core code into one engine

proposed methods of actually doing the thing

• basically the process is to identify the least risky controllers and add them, but what happens when we get to a risky one?
• or add them all at once - this also is scary..

todo

• get gaba on the new block tracker (debatable as an implementation detail if gaba doesn't require it)

• test parity/coverage between coverage of metamask controller and the gaba controllers

  • going through current mm and gaba, identifying gaps in test coverage and comparing outcomes/behaviour by the test suites. gaba is well unit tested, the extension, less so

• test mm provider config in gaba

• mm extension and gaba do not currently have controller parity see current extension vs gaba

  • remove unused controllers in mm

    • userActions
    • computedBalances

  • remove networkStatusController - used to check infura status (remove in extension and in gaba)

  • get existing controllers to feature parity

    • txController
    • networkController (chainId)

• map the network change event dependencies in the mm extension

• currencyRatesController extension PR needs updated migration

• determine safe order for bringing in controllers

outstanding questions

• why does not having gaba block incoming transactions? - we use etherscan api for this, nothing fancy

• how to develop features on both gaba and the extension once we have gaba in for a lot of the controllers

• how the update code works

• NetworkController export interface ProviderConfig { //TODO }

• how the provider is used in all the controllers

  • verify that the network controller updates on provider change and that siblings correspondingly update correctly

• identify if the provider is used in any other of the gaba controllers outside of the expected networkController

  • AccountTrackerController uses EthJsQuery
  • AssestsContractController uses Web3
  • TransactionController uses EthQuery
  • NetworkController uses EthQuery

• why is the networkController using the web3-provider-engine Subprovider?

concerns

• even if we've reduced the total number of modules, we have also reduced the number of modules that we have explicit control over, like the uuuid in tx controller

• the existing mm code has been battle tested, gaba less so -> unproven future (how many bugs will we have to fix again)

benefits/potential pitfalls

benefits

• collectibles support in extension
• one engine codebase (ish)

pitfalls

• developing device specific (mobile vs extension) implementations/features
• plugin system in typescript? ocap? contract accounts?
• how well do existing controllers play with gabafied core components
• lots of work required

preferences controller vs gaba preferences controller

• gaba preferences controller is missing locale data, this is important for the extension, implemented differently for the mobile app...mobile: try to match the device lang with our available langs, if there's no match we default to english and can be changed under settings
  • possible solution: gabify (gaba-fy?) the preferences controller with locale, rpcList, etc

Transaction Controller

breaking behavior:

• #addTransaction will fail a transaction if estimate gas fails
• missing rebroadcast
• gaba is missing txHistory
  • sort/filter functionality of txHistory
• debug history diffs on txMetas
• has no concept of dropped as a status
• txMetas might be missing .metamaskId //look into whether this is important

needs improvement:

• no intelligent nonce calculation
• #approveTransaction : if the current networkId is not defined, gaba txController defaults to 1 https://github.com/MetaMask/gaba/blob/master/src/TransactionController.ts#L322
• file readability (break into multiple files)

network controller notes

see outstanding questions The network controller overall is very different given the nature of gaba's update base class method...

• ensure that network switches are handled properly
• still uses 'web3-provider-engine/zero.js'
• missing chain id specification
• should be the last controller to be swapped out in the extension due to update/broadcast changes
  • possibly intermediary step: nest the gaba networkController in the mm networkController

current extension vs gaba

needs to be gaba'd

• CachedBalancesController

not used in extension

• ComputedBalancesController
• InfuraController (NetworkStatusController in gaba - does seem to be used in mobile fwiw)

not in gaba - are they needed?

• ProviderApprovalController

• RecentBlocksController

advantages

• GABA allowed us to build mobile. MetamaskController barely worked in mobile and required over 1000 3rd-party modules and many hacks to work.
• Core and UI(s) can iterate independently and more rapidly
• Existing and new clients can leverage a stable, versioned, documented data model
• Puts forth a common, MetaMask-agnostic engine to the broader ecosystem
• Auto-generated CHANGELOGs and API documentation
• Modules maintain 100% code coverage and are fully documented and linted
• Modules are written in TypeScript so interfaces are enforced
• By side-effect we get a clean core-specific issue tracker on a new repository

diagram of dependencies

necessary for compose

on the right are the gaba controllers with no gaba sibling deps

did list

• read gaba
• merged in addressBook - so far no issues (was easy to test and low risk)
• made this doc (wip)