I'm curious about how Amethyst does the current translation, , and if there's a way to optimize it? For example, if somebody spends tokens to get a really good translation, then it would be nice if the translations could be shared (or sold?) to other users Maybe there is a paid relay that offers great translations already

My next step in the cashu spilman channel will be a 'client proxy' and a 'server proxy'. The server proxy will sit in front of typical services like Nostr relays or Blossom, but they will enforce payment and will raise 402 errors if the payment is missing Similarly, the client proxy will run on your device to insert the payment into the request before it's send to the server Blossom seems like a good place to start, to charge for uploading; I checked a few details about the protocol today, BUD-02 allows to upload to one server (the server proxy) where the server proxy will 'redirect' the client to the *real* Blossom server for future reading, and I think that typical Nostr clients will 'do the right thing' when they are behind the proxy It should be easy for us to extend the functionality of this 'server proxy' over time. Nostr and Blossom today, but it could wrap other things in future

Even your browser is just ESP32 now "Emulate Arduino, ESP32 & Raspberry Pi. in your browser. Write code, compile, and run on 19 real boards" https://github.com/davidmonterocrespo24/velxio

A tiny Cashu Spilman channel update; I should make these more often: While the server side (i.e. payment receiver) code is in a reasonable state for now, in terms of flexibility and a clear state machine, I'm now catching up with a similar approach on the client side Just today, I'm adding an 'Opening' state to the client, just before 'Open'. The client opens a channel by creating a 'funding token' with the mint, a token which is in a 2-of-2 multisig very similar to a Lightning channel. If the swap (or melt) which creates that fails (or *appears* to fail, from the client's point of view), then the client should probably try again or use NUT-09 to get the response. So I'm implementing and testing that now https://github.com/cashubtc/nuts/blob/main/09.md The code is now a library which depends on the CDK, i.e. no longer a (disorganized!) fork of the CDK: https://github.com/SatsAndSports/cashu_spilman_channels/blob/main/ARCHITECTURE.md#channel-lifecycle-server-perspective

An alternative that's more flexible, and perhaps safer because it's not an (auto-updating) npm package: https://github.com/rynfar/opencode-claude-max-proxy

Maybe yours is better actually :-) Anyway, maybe we need a convention for an AGENTS_LOCAL.md file, which includes more 'personal' preferences of the developer, or other details ('Use podman instead of docker when executing on my machine'). For example, I prefer to do the 'git' operations myself, but other developers of the project might have a different policy

As some context to why I'm sharing this, here is the initial report it sent after working for 19 minutes on a big change. It's the generic "big update all complete, sir/madam": But sometimes (not in this particular case), there are important surprises that don't surface including bad micro-decisions that I have to challenge later

After big code changes, ask your agent if there were any surprises while it was working. I always find it interesting; sometimes it raises important details that it otherwise wouldn't have told me about Ask it what changed and what didn't. If you think that a particular task is a conventional refactor of a particular module and it shouldn't affect any tests or any other modules, it's good to verify this afterwards

I know smart people are working on this, and I'm curious what the end state might be OpenTimestamps might be needed, but even that's incomplete; it can't give real time certainty, due to the fact that we get bitcoin blocks only every ten minutes My guess is that we'll need "fork-aware" Marmot clients which tell the user about forks and ask the user to choose which to follow