HomePhabricator

[Cashtab] [Alias-server] - pt 1 - Alias server api integration

Description

[Cashtab] [Alias-server] - pt 1 - Alias server api integration

Summary:
T3003

Pretty big refactor but they couldn't be split out into smaller diffs as they're all interconnected.

Refactored logic:

  1. Upon Cashtab loading, if the alias setting is enabled in Ticker.js, then handleUpdateWallet in useWallet.js will execute synchronizeAliasCache.
  2. synchronizeAliasCache calls getAliasServerHistory to hit the alias-server to retrieve the latest valid aliases and if the alias count does not match between aliasCache.aliases and the alias-server, then localforage is updated via updateAliases
  3. When updateAliases is commiting the alias-server response to the cashtabCache.aliasCache object, it now looks like:

aliasCache: {

aliases: [],
cachedAliasCount: 0,

},

The integration with alias-server made all processes relating to parsing paymentTxHistory, extracting valid aliases, parsing onchain count...etc redundant, hence a much simplified aliasCache object going forward.

  1. When the user is registering a new alias, isAliasAvailable and isAliasRegistered are called to check whether it has been taken.
  2. If alias is available, the remaining registration logic remains unchanged, other than now calling registerAliasNotification for successful notification that explains the need for 1 conf for alias to be active.
  3. Upon registration, processChronikWsMsg in useWallet.js (from the abandoned D13301) will wait for a new block to be found and then refresh the aliasCache so the newly registered alias will show up in registered aliases list in Alias.js and resolve to the appropriate address in send and sendToken screens.
  4. Also fixed an existing bug in Alias.js where synchronizeAliasCache was returning an outdated aliasCache IF it determined a cache refresh was required i.e. it was originally returning the aliasCache that was retrieved at the start of the function before the refresh action. Now Alias.js' useEffect calls await synchronizeAliasCache() first then directly retrieves latest from getAliasesFromLocalForage()` afterwards
  5. Various unit tests and mocks updated to reflect the above refactors and the new aliasCache object

Refactor Change log

updated

  • updateAliases: now takes in the alias server response and commits it to localforage
  • synchronizeAliasCache: compares onchain vs cached alias count and updates the latest alias-server response into local storage when required
  • isAliasAvailable: retrieves alias list from storage rather than hitting chronik
  • send.js now passes cached aliases into isAliasAvailable rather than chronik instance, as well as updated error message "eCash Alias does not exist or yet to receive 1 confirmation"
  • sendToken.js: updated error message "eCash Alias does not exist or yet to receive 1 confirmation"
  • isValidCashtabCache: updated to reflect the new aliasCache structure
  • getAliasesFromLocalForage: returning the updated aliasCache object but kept the alphanumeric validation in there to migrate pre-alias-server wallet caches
  • processChronikWsMsg: monitors for a new block and then triggers an alias cache update

Removed

  • getAllTxHistory: no need to hit chronik anymore
  • getAliasAndAddresses: redundant now the alias-server does the heavy lifting to parse payment tx history
  • calculateAliasTxCount: redundant now that we're using alias count
  • sortAliasTxsByTxidAndBlockheight: redundant now the alias-server is doing this
  • filterDuplicateAliasTxs: redundant now the alias-server is doing this

Unchanged

  • isAliasRegistered: local caching logic only
  • isAddressRegistered: local caching logic only
  • isAlphanumeric: kept for getAliasesFromLocalForage
  • getAddressFromAlias: local caching logic only
  • isAddressRegistered: local caching logic only
  • getAliasRegistrationFee: local parsing only
  • registerNewAlias: still broadcasting via chronik

New

  • getAliasServerHistory: fetches the alias server response
  • registerAliasNotification: as advertised

Test Plan:

  • npm test
  • enable alias in ticker.js
  • npm start
  • retest alias input validation for valid alphanumeric inputs, invalid inputs (uppercase, spaces, symbols, special chars, emojis)
  • register a new alias and ensure it is initially not displayed on the registered alias list nor resolves to any addresses in send/sendToken
  • wait for a new block to be found and observe the New block found, updating aliasCache message in console log
  • ensure the new alias is now reflected in Alias.js' registered aliases list and now resolves to the correct address in send/sendToken screens
  • register another new alias, close cashtab, wait for 1 conf, then re-open cashtab and ensure via console log the onchain vs cached alias count does not match and it still triggers an aliasCache update
  • disable alias in ticker.js and ensure nothing blows up, wait for 1 block to be found and ensure no errors in console log

Reviewers: bytesofman, #bitcoin_abc

Reviewed By: bytesofman, #bitcoin_abc

Differential Revision: https://reviews.bitcoinabc.org/D13367

Details

Provenance
emackAuthored on Mar 17 2023, 02:37
emackPushed on Mar 27 2023, 00:59
Reviewer
Restricted Project
Differential Revision
D13367: [Cashtab] [Alias-server] - pt 1 - Alias server api integration
Parents
rABCfd8c164b6e6c: [symbol-check] bump glibc to 2.27 and gcc to 8.3
Branches
Unknown
Tags
Unknown