I thought the spec said that files with identical content should always produce the same hash, but in practice, that doesn't seem to be the case. It looks like the hash is being generated by including metadata such as upload time as well.

Even if it's possible to make the exact amount with the current token combinations, it still ends up using just the tokens I have on hand, which can result in multiple inputs—like sending 256 using two 128s, for example. Swapping to send a single 256 token looks cleaner. But would making that the default behavior be wasteful due to the extra network round trip?

It would be great if, when issuing tokens, it could automatically send the exact amount using the minimum number of tokens—like finding the optimal combination. If the available tokens can't form the precise amount, it could fetch suitable denominations from the mint to make up the difference. It would be convenient if this were handled automatically at the library level. Do you know if such a feature already exists?

Yeah, that's right. I've seen others solve it by creating animated QR codes, but that brings compatibility issues and loses the charm of printing and handing it over, lol. But if we just make it tiny and packed, it probably won't scan well either... For now, I'm just sticking to issuing tokens in denominations that match Cashu's unit (like 256 or 128), so I don't need to include that many tokens anyway—this works fine for me.

There's a feature in Keychat wallet where sending "pay ecash" returns an ecash token, but sometimes it comes with a QR code and sometimes it doesn't. What's the difference? I'd like to provide a smooth experience where users can simply pass along a QR code, but when it only returns a token, I have to send it via DM, which is a bit inconvenient. #asknostr

Also can I convert my current balance into an eCash token form and send it to someone else? I'm trying to transfer the full amount cleanly without leaving change in my yakihonne wallet.

Is it not possible to receive a Cashu token in the form of a QR code? I thought the "Redeem" option at the top was meant for that, but it doesn't seem to work.

Sometimes, while using a VPN, Nostr-related apps occasionally fail to work properly. Since they always start working again as soon as I turn the VPN off, it's nearly certain that the VPN is the apparent cause. I initially thought the VPN might be blocking WebSocket connections to relays, but since the apps often work perfectly fine even when the VPN is on, that doesn't seem to fully explain it. What's more puzzling is that always works without any issues, regardless of whether the VPN is active or not. I can't figure out the reason for this inconsistency.

Full compatibility? cool. Does it provide migration support for makers? Those with fidelity bonds might find switching difficult, so it would be ideal if simply copying the existing data folder would allow full functionality.

jumble is my favorite client in terms of UI, but it definitely has a bit of a loading lag—especially during initial startup. I've always thought that Nostr clients would benefit greatly from an architecture where a separate background process handles subscription to relays and manages writing events into a local database. Would the development complexity increase drastically with this approach? Perhaps, but I believe the advantages gained from such a design would be substantial. While completely rebuilding existing clients might not be practical, I hope developers creating new clients will seriously consider this kind of architecture.

I'm currently using the Qwen3 235B A22B 2507 model. Are there any newly released models that offer better performance and better cost-effectiveness? For example, models with nearly similar performance but significantly cheaper, or slightly more expensive models that deliver much better performance? Performance criteria can be based on general user experience.