Nice, that’s great to hear and comes at the perfect point of time! I’m sure there will be some further questions / suggestions when it comes to the details of the API, but at a first glance this seems like exactly what we need for BIP324 Proxy. Just being curious, what was the motivation to reduce the cryptography dependencies and reimplement them? Do the available Rust crates have any significant drawbacks, or is that more a generic philosophical decision of the library? I’m not saying it’s a bad idea (we actually do the same in Bitcoin Core), I just assumed that in Rust the package management works well enough, and I think I wouldn’t have a problem depending on a well-maintained cryptographic library, which ideally has the resources to investigate optimizations etc.
As a small update, I’ve started the Rust rewrite branch yesterday: GitHub - theStack/bip324-proxy at rust_rewrite It’s still tiny, so far it only creates the local server socket and displays a mesage for an incoming client connection, without spinning up a new thread yet. The plan would be to implement a dummy proxy (v1<->v1) first and only then plug in all the BIP324 related stuff. Let’s see how that goes. As always, contributions in any form are welcome (even if it’s recommended book material / common pitfalls for network programming in Rust or whatever).