ICRC-2: It is practically impossible for users to manage allowances

[dostro]

The ecosystem needs an app like https://revoke.cash/ that gives users an easy way to manage their wallet's allowances, but this is practically impossible because the app can't look up allowances by principal/account... it also needs the spender principal/account specified as the query parameter.

The only other way to give users a way to manage allowances is for every wallet to implement its own allowance management feature, but this is practically impossibility. Imagine users export PEM from one wallet and import into another... they'd also need to export a map of allowances.

Can we make spender principal/account an optional parameter for the icrc2_allowance query?

[MarioDfinity]

Hi @dostro, we are considering a new endpoint that lists all the allowances. An issue we have is that the ICP Ledger doesn't store this information so some changes may be needed in order to support this new feature. I'll keep you posted on the progress, we are going to have a meeting about this in the next WG (/cc @dietersommer) and also internally at DFINITY.

[skilesare]

You should be able to derive these from the transaction log. An Indexing standard has been talked about for a while and maybe this should go there. It should be easy to pull all approval transactions from an indexer and then query if they are still open(a batch equivalent to ICRC-4 for transfer approve would be helpful here....it is on my list of things to do, but currently not a high priority).

[dostro]

Hi @dostro, we are considering a new endpoint that lists all the allowances. An issue we have is that the ICP Ledger doesn't store this information so some changes may be needed in order to support this new feature. I'll keep you posted on the progress, we are going to have a meeting about this in the next WG (/cc @dietersommer) and also internally at DFINITY.

I believe we need this new endpoint for allowances by account.

You should be able to derive these from the transaction log. An Indexing standard has been talked about for a while and maybe this should go there. It should be easy to pull all approval transactions from an indexer and then query if they are still open(a batch equivalent to ICRC-4 for transfer approve would be helpful here....it is on my list of things to do, but currently not a high priority).

Anything more complicated than a single endpoint to get allowances by account is, IMHO, too difficult for such a small ecosystem to adopt. The reason I opened this issue is because I was starting to design allowance management for NFID Wallet and found that the amount of work required to adopt this standard is too much to justify supporting it. We can't be developing a custom implementation that other wallets would also need to duplicate, and that breaks without more infrastructure/standards if users migrate PEM files across wallets.

[skilesare]

The issue is keeping the ledgers simple. An index by account ID can:

1. Grow to exceed canister capacity(or at least cycle limit capacity)
2. Chews up processing and reduces throughput.

We have at least three solutions for this in the idea/implementation phase:

1. Standardize the Index server. Each ICRC-1,2,4,7,37 canister should have an indexing server that allows simple queries like this. DFINITY already has one that uses the legacy block structure that each SNS gets. For example, for ckBTC just hit this: https://dashboard.internetcomputer.org/canister/n5wcd-faaaa-aaaar-qaaea-cai and query for the user's transactions(you're probably already querying something like this to show their activity). You just need to filter the list of approved transactions and the last one to each address that is non-zero and non-expired is the approval value. I'd love to standardize this into an ICRC and I'd be happy to write a Motoko indexer for the Motoko ledgers out there....or if DFINITY does one for ICRC3 then Motoko canisters can easily use it by deploying and pointing at the ICRC3 log.
2. The event utility we're building will allow a user to create a subscription and then request playback of some items...may cost some cycles but a canister wallet could create these subscriptions and just listen and be always up to date.
3. We've thought about a generic CanDB indexer that can point to any ICRC3 log and make it quickly queriable.

Option 1 above is already available for all SNS and ICP tokens which likely gets you 95% of the ecosystem. It should not be a big lift. Maybe for some huge accounts with thousands and thousands of transactions it might be a bit slow...but if you use some web storage you can optimize it to only check for updates.