Change Details

Updates Cashtab to handle pending aliases via the `/address/` endpoint. Design considerations: - When the user broadcasts a new alias via Alias.js there is network propagation time to consider before the pending alias is picked up by alias-server and exposured via the `/address/` endpoint. - To mitigate this, the newly successfully broadcasted alias is locally appended to the existing pending dropdown list in Cashtab. - This ensures the user will not notice any delay in the UI between the point of registration broadcast and the next alias refresh interval, which is up to 30 seconds, which will then re-sync Cashtab with the updated pending list from alias-server. - If the pending alias was not successfully confirmed for this wallet, the alias refresh interval will reflect this between the `Registered Aliases` and `Pending Aliases` dropdowns. - There is a potential edge case where the user broadcasts a registration right before a scheduled interval alias refresh, and if the pending alias was not propagated to alias-server for that particular alias refresh event, then that local pending alias would disappear from the pending dropdown. However this is only temporary because the subsequent alias refresh interval (within 30 seconds) will bring it back in sync using the updated alias-server data as the source of truth. Hence I believe this rare occurance is negligible.

Updates Cashtab to handle pending aliases via the `/address/` endpoint. Design considerations: - When the user broadcasts a new alias via Alias.js there is network propagation time to consider before the pending alias is picked up by alias-server and exposured via the `/address/` endpoint. - To mitigate this, the newly successfully broadcasted alias is locally appended to the existing pending dropdown list in Cashtab. - This ensures the user will not notice any delay in the UI between the point of registration broadcast and the next alias refresh interval, which is up to 30 seconds, which will then re-sync Cashtab with the updated pending list from alias-server. - If the pending alias was not successfully confirmed for this wallet, the alias refresh interval will reflect this between the `Registered Aliases` and `Pending Aliases` dropdowns. - There is a potential edge case where the user broadcasts a registration right before a scheduled interval alias refresh, and if the pending alias was not propagated to alias-server for that particular alias refresh event, then that local pending alias would disappear from the pending dropdown. However this is only temporary because the subsequent alias refresh interval (within 30 seconds) will bring it back in sync using the updated alias-server data as the source of truth. Hence I believe this rare occurance is negligible. - Upon alias-server outage, I purposely did not set a pop up alert for this otherwise an extended downtime with alias-server will result in a constant pop up every 30 seconds courtesy of the refresh interval regardless of which page the user is on.

Updates Cashtab to handle pending aliases via the `/address/` endpoint. Design considerations: - When the user broadcasts a new alias via Alias.js there is network propagation time to consider before the pending alias is picked up by alias-server and exposured via the `/address/` endpoint. - To mitigate this, the newly successfully broadcasted alias is locally appended to the existing pending dropdown list in Cashtab. - This ensures the user will not notice any delay in the UI between the point of registration broadcast and the next alias refresh interval, which is up to 30 seconds, which will then re-sync Cashtab with the updated pending list from alias-server. - If the pending alias was not successfully confirmed for this wallet, the alias refresh interval will reflect this between the `Registered Aliases` and `Pending Aliases` dropdowns. - There is a potential edge case where the user broadcasts a registration right before a scheduled interval alias refresh, and if the pending alias was not propagated to alias-server for that particular alias refresh event, then that local pending alias would disappear from the pending dropdown. However this is only temporary because the subsequent alias refresh interval (within 30 seconds) will bring it back in sync using the updated alias-server data as the source of truth. Hence I believe this rare occurance is negligible. - Upon alias-server outage, I purposely did not set a pop up alert for this otherwise an extended downtime with alias-server will result in a constant pop up every 30 seconds courtesy of the refresh interval regardless of which page the user is on.