Postgres has a levenshtein distance function already so we can use that as MVP. Transpositions cut costs more than I'd like but it's better than nothing.

Is the intent to show the cost of a nym change to a user before they submit the request? I ask because relying on a postgres fn to calculate it seems like it might be somewhat inefficient, requiring us to go to the DB to provide the cost estimate up front. If that's the case, it might be worth finding a js lib that can calculate the levenshtein distance so we can do that calculation on the client?

Edit: I guess maybe it's still worth using the postgres fn since we'd have to calculate the distance against all existing nyms, so not transferring that much data over the wire is better. I'm just thinking out loud at this point lol

Is the intent to show the cost of a nym change to a user before they submit the request?

Yes. Our current rule of thumb is that if any action costs more than 1 sat, show a receipt upfront (zapping excluded).

Yeah we'll have to beat up postgres either way. We already go to the db to check if a name is taken, so we could piggy back on that.

This piques my interest. I'll start looking into an implementation.