In the early days of ecash a common narrative was that it provides "theoretically perfect anonymity", but there's more nuance to this. 

It's correct that when the client presents an unblinded signed message, the mint cannot link this to any specific blinded cyphertext that it signed previously. 

However, there is still three pieces of critical metadata that the client does reveal:

1. The number of inputs and outputs of the ecash transaction. Transactions with many inputs reveal that the same user got paid many times in the past. Transactions with many outputs reveal that one user is making many payments.

2. The value of each input and output. The mint uses a different key for each denomination value of the tokens. Thus a token worth 5 units is easily differentiated from a token worth 10 units. The anonymity set of a token depends on the number of tokens generated, so if a user is the only one with that specific denomination he has no privacy. 

3. The IP address that connects to the mint to send the transaction api request. If the same IP address makes multiple payments, it's likely the same user, and his geolocation is also revealed.

Problems 1 and 2 can be mitigated on client side, but this adds substantial complexity in utxo management and transaction structure. If these mitigation are not specified and different clients have slightly different solutions, this opens up additional client fingerprinting attacks.

WabiSabi is designed to solve problems 1 and 2 on a protocol level. A WabiSabi transaction is required to have exactly two inputs and two outputs, and homomorphic value commitments hide the amounts of each input and output. The tradeoff is that the mint has to issue 0 value credentials, a user needs to make more transactions to prepare his desired amounts, and the proof size and creation time is larger.

Problem 3 is addressed by a client side networking anonymity layer. A VPN at least hides the actual users IP address, but if only one client uses this VPN to talk to this mint, it's still one IP per user. Tor is incredibly useful here, as it allows the creation of anonymous onion routes through the network with different exit IP addresses. A client can get a new IP for each api request! This does however increase bandwidth and latency cost.

We should assume "everyone knows what the mint knows", and so we need to be hardcore about privacy protections best baked into the protocol. If the protocol doesn't ensure the security of the user, client devs have to do an exponentially larger amount of research and development to fix the issues client side.