As per T2551, this diff is the base implementation of how namespace aliases would work in Cashtab.

(I will send you the backend API keys on tg)

Workflow:

1. User opens cashtab, navigates to the Receive page which will automatically check whether the active wallet's eCash address is attached to an existing alias

2. If this address is already attached to an alias then it will be displayed

3. If this address is unattached, then a registration input field will be rendered for the user to register an alias for their address.

4. If the chosen alias already exists, then an error will be displayed

5. If the chosen alias is unique, then it will be committed to the backend

3. Any cashtab user can simply input this alias into the address field and it will be converted to the equivalent ecash address in the backend prior to the tx being broadcasted via chronik.

Implementation:

• useWallet.s initializes the Backendless connection and makes the instance available to the rest of cashtab via ContextValue.
• Receive.js checks for any alias attached to the active wallet's address upon loading, which then conditionally renders the alias registration input
• Send.js' eCash address validation now detects whether an input ends in '.xec' and if so, bypasses existing eCash address validation logic and calls sendXec() with aliasFlag set to true
• useBCH.js' sendXec() function now takes in an aliasFlag will lookup the .xec alias for a corresponding address and override the destinationAddress
• the backend structure is as follows, with an eye on future expansion of identity management across the eCash ecosystem:

[

{
   "created":1664721736330,
   "alias":"ethan.xec",
   "ecashAddress":"ecash:qq9h6d0a5q65fv4ry64x04ep906mdku8f0gxfgx"
   "etokenAddress":null,
   "discordId":null,
   "redditId":null,
   "ownerId":null,
   "telegramId":null,
   "twitterId":null,
   "___class":"xns",       
   "updated":1664721760079,       
   "objectId":"588D2A9A-9F38-4F44-880E-CB4D01DC3F06",
}

]

Subsequent diffs will depend on ongoing discussions in T2551, including:

• whether to adopt onchain issuances of tokens so namespaces are tradeable on DEXs
• sybil resistance and mitigation for users hoarding valuable names
• potential fees
• whether aliases should expire and thus require renewal

• npm i backendless
• npm start
• navigate to the Receive screen on a fresh wallet and observe no existing alias attached and the registration input field is rendered
• register a desired alias and observe a success notification and the subsequent update of the alias field, which will then hide the registration input field
• use the newly registered .xec alias in the send field and ensure it is sent to the correct address
• navigate back to the Receive screen and ensure the registered alias is displayed and no rendering of the registration input field