Whatever is done for App.js should also be done for extension/src/components/App.js

If passLoadingStatus is necessary, it should be provided here

If not necessary, should be removed from the Identity component

Might as well give it a good placeholder icon here, at least something that is unique.

<CheckCircleOutlined /> from antd default library would work. Open to other suggestions.

https://ant.design/components/icon

This should be added to /web/standards/op_return-prefix-guideline.md in the same diff

Instead of setting it to be a string, it should be initialized as false or null. Then there should be conditional rendering on what to say if alias is false or null.

In this case, null probably makes the most sense. When the page loads, the app doesn't know if the user will have an alias or not. After Cashtab figures this out, perhaps alias is set to false or true (if this is simply being used as a boolean...in which case mb something like hasValidAlias would be a better name). Or it becomes an array, either empty if no valid aliases or populated if the address has valid aliases registered.

Cashtab has been a bit sloppy in implementing this stuff properly from the get go in the past. We should put some thought into how this variable will be used.

Since this will be a standard, no need for us to put it in all the registering transactions. Limits the namespace available.

Also, maybe we don't want the standard to be "all aliases end with .xec, or maybe it changes someday.

Alias registrations should be just the desired alias.

This will depend on the character length of the desired alias. So, we will probably want to keep this as an object or array in the currency object in Ticker.js

We won't really know if it's available until at least 1 conf on the tx. So will still need to handle a pending state.

Can filter this further with "for each incoming tx with OP_RETURN inputs that paid at least minFee"

In theory, a single address could have multiple valid aliases.

We could make some kind of rule to prevent this, but I don't think we should. Mb someone wants 10 aliases for the same address, or someone is speculating on the value of alias NFTs in the future.

see above. I think it's more work to exclude the possibility of multiple aliases for one address than it is to simply allow it. Some users might want it.

Every alias must match to one and only one address.

But it's okay for an address to match to many aliases.

This should be handled in the background of the Send.js component before the "send tx" button is enabled. So, we do need this function, but I don't think transactions.js is the right place for it.

This is a novel way to save time in this function. Because it's also used in other alias verification functions, it should be its own function, something like isLocalAliasStateLatest

In the (unlikely but possible) event that firstTimeSeen is lower for one alias registration tx, but a later transaction for the same alias confirmed sooner, we want to defer to the first confirmed and not the first seen.

Once we set these rates, it will be pretty much impossible to change them.

Also, we probably will not want to test with whatever final prices are.

So, we should have something here like

{
oneChar: 150,
twoChar: 125,
threeChar: 100,
fourChar: 75,
fiveChar: 50,
sixChar: 25,
sevenChar: 20,
eightChar: 15,
minFee: 10,
}

In this way, we can write code that parses for variables like aliasRegistrationFeeInSats.oneChar -- test with a lower fee table than what goes into prod, but not have to mess with the functions to update pricing before deployment.