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

Updated rendered messages

Updated dependency

Updated author and payload labelling

is there any expected byte length here? what makes it unique? what happens if someone starts broadcasting clones of these txs ... there's no way to guarantee this is unique since it is public.

Updated authentication tx msg and added reference to spec

Updated article paywall render to be an explorer link, removed invalid article id renders and added reference to spec.

version bump

Updated comments

Clicking the copy icon for txid at the top gives this

@bot preview-explorer

version bump

version bump

Added stackArray size check and updated int tests

Accepted subject to a decision on plugin use vs current implementation

On a semi related note, not for this diff, but if you try to use a non-jpg/png file (e.g. webp) for the NFT collection it crashes the app (blank white screen), with the console spitting out TypeError: Cannot read properties of undefined (reading 'size').

Moved maintenance toggle to .env, removed ETA in messaging and the unnecessary reference to funds

Updated message

In D16510#373511, @emack wrote:

Semi-related nit: Update CONTRIBUTING.md to run this docker build -f cashtab.Dockerfile -t cashtab_local . before you can hop into the Cashtab repo and run docker-compose build, otherwise it will fail due to no config files. Alternatively just add this step to Cashtab README's dependency paragraph in the Development section.

Semi-related nit: Update CONTRIBUTING.md to run this docker build -f cashtab.Dockerfile -t cashtab_local . before you can hop into the Cashtab repo and run docker-compose build, otherwise it will fail due to no config files. Alternatively just add this step to Cashtab README's dependency paragraph in the Development section.

Accepted with minor nit