Pretty cool seeing an orderbook on ecash!

WSOD as per tg chat

Not for this diff but tickers sound like something we should be mandating during token creation. It's an easy alternative to token id to separate identical tokens. But if we do mandate it then it's worth tracking whether a ticker already exist.
I also checked etoken creation and it's not mandated there either.

accepted with minor nits

Following chat on tg, issue was on ecc app side. Extension now testing all ok.

Desktop and mobile tested all ok via BIP21 url querystring, with different amounts, decimals and addresses

Minor nit

When loading the NFT component it is complaining of a type error. Only appears on this diff and not on master.

version bump

• I did a quick grep and there's no documentation on the chronik.lokadId() API, which is exclusively on in-node chronik?
• Maybe outside the scope of this diff, but can do with a production considerations section that talks to the various production challenges e.g. retrieving an address' history since inception can be tricky, as it's typically larger than the max number of pages retrievable per API call (200 pages). In which case the doc should recommend retrieving the first page so you get the numPages property which can be used to then work out the appropriate history pagination or to loop through and build up an array of promises for concurrent execution.

minor nit

@bot ecash-herald-tests

Minor nit

version bump

Are these the equivalent of node_module files for react apps and can be ignored?

grep should be grep -r ChronikClientNode src/ otherwise it'll return all the ChronikClientNode references in node_modules

In D16654#377310, @emack wrote:

Just so I'm understanding this correctly, there's no need to update package.json here to pick up the new chronik-client with the deprecated legacy ChronikClientNode constructor? Because it's on a relative path? But external apps using the chronik-client will right?

Just so I'm understanding this correctly, there's no need to update package.json here to pick up the new chronik-client with the deprecated legacy ChronikClientNode constructor? Because it's on a relative path? But external apps using the chronik-client will right?

Rebase to master and version bump

Updated with on-spec but empty identifier condition

We probably need some comms on this along the lines of:

1. next version is a breaking change for apps using NNG
2. For existing in-node apps, refactor all references to ChronikClientNode to be ChronikClient
3. For existing NNG powered apps, keep in mind changes a, b, c...... e.g. using address.history() going forward instead of script.history()

beyond the scope of this diff -- but why different lokad id for all of these things that are different functions of ecashchat?

Updated author

Updated to parse hex article txids and updated off spec messaging