At that point you can do key derivation to get an ed25519 private key from the password and a server-supplied salt (specific to that user), after which the client signs a challenge the server supplied with that private key. When the password was set/changed, the corresponding public key was stored on the server.

Off the top of my mind. Maybe it could be something like that:

1. Api gives user a fixed salt.

2. User types password into input.

3. Client hashes and sends hash to server.

4. Server has another salt and uses the client sent hash to hash it again.

5. This final hash is compared what is in the database.

This way server never has knowledge of the original PW and it's never sent over the network. This reduces for instance the chance of password getting logged in the service etc.

But in that case the hash sent to the server in stage 3 is always the same and behaves like a password - capture it and you can use it again elsewhere.