Code looks good, but I'm not sure about the API. What is the chance an app has the need for both native and slp utxos ? If only one is needed then only returning the desired subset could lead to a much lighter returned object and thus better performance. What do you think ?

• Can we keep the original functionality of the script.utxos() call so that this is not a breaking change?
• Possible to add new method to get the utxos split out, as diff currently does?
• Possible to add new method to get either one or the other, as Fabien suggests?

@bytesofman - does this diff need to wait till D14271 lands, followed by running npm publish?

Also verified via local npm installation of this diff on a test script
npm install ./chronik-client

const { ChronikClient } = require('./chronik-client');
const chronik = new ChronikClient('https://chronik.fabien.cash');
const ecashaddr = require('ecashaddrjs');

async function getUtxosFromAddress() {
    const { type, hash } = ecashaddr.decode('ecash:qq9h6d0a5q65fgywv4ry64x04ep906mdku8f0gxfgx', true);
    const utxos = await chronik.script(type, hash).utxos();
    console.log(utxos);
};

(async () => {
    await getUtxosFromAddress();
})();

Diff looks good. Talking with @tobias_ruck -- he has some reservations about merging this due to upcoming have-to-happen changes in chronik-client, lack of backward compatibility, and overcomplicating the API.

imo having a way to get only xec utxos or only slp utxos is a net win, since otherwise you must get all the utxos from a server and filter out what you don't need.

In the meantime, @emack, let's just get the examples diffs rolling again without this. May have a window for landing this in the series of chronik-client upgrades needed to support the in-node version.

Per feedback from @tobias_ruck , we can abandon this one for now. It simplifies the examples/ scripts but is not necessary for wallet devs. Can be revived if we later decide the functionality is required.

For reference, here's some points I raised with Joey and Fabien (redacted somewhat):

I’m not really convinced this is an improvement, why would you group it by XEC vs SLP? Wouldn’t you also want to group the SLP tokens by token ID? The intention behind chronik-client was mostly to provide a easy to use client to access the data coming from Chronik. Wouldn’t it make more sense to add a auxiliary library for this, which can provide a wrapper around chronik-client?

Frankly I don’t really need this splitting (I filter by token ID), and I think there’s a danger that we add too much post processing to chronik-client, kinda inviting the devil.

An even better approach for the future might be to have Chronik filter by XEC-only/token ID A/token ID B, etc. server side.

Right now I’m just unhappy with the proposed API because the application isn’t very clear. It’s still not clear to me why this is really needed. It’s such a simple operation; but it often has to be tailored to the specific use-case. The scope of this improvement is very narrow (it doesn’t benefit me for example), and for most SLP wallets it’s not sufficient either. Really the only place where it’s useful is XEC wallets that are SLP aware, which is very narrow.

What’s wrong with adding the filtering to e.g. a xec-js library? That way we can keep it decoupled. chronik-client can focus on what it’s best at (a thin reliable client for Chronik), and eg xec-js can focus on providing a simple to use API to the XEC world.

The issue is not with this particular change, it’s with the future changes that will be added. Those will always be opinionated, and have tradeoffs. And those should be done. They will simplify the dev UX massively. But I think it’s better to have each library focus on what they’re best at.

Also, considering that there will be slight changes when we migrate to the native Chronik version, plus changes based on SLPv2, is why I’m a bit skeptical of adding stuff like this already, it’ll make upgrades harder as the design starts to ossify. I’d rather take a holistic approach, look at the goals of the library and design it accordingly, instead of adding stuff as we see fit.

There’s also other issues; like the usage of xec in the name, it’ll make it awkward to use for XPI users (Stamp is already using the library).

IMO, chronik-client should stay thin, and there should be a library around it with all the fancy more specific stuff. Another option would be to have a fork with a new library name on npm for it where you can do the XEC specific stuff, but I like that less than the layered approach. There’s some inherent complexity here which I don’t think one can remove simply, for what you guys want to do, it either has to be a forked chronik-client or a layered approach.