Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle nym similarity #580

Open
huumn opened this issue Oct 23, 2023 · 4 comments · May be fixed by #588
Open

Handle nym similarity #580

huumn opened this issue Oct 23, 2023 · 4 comments · May be fixed by #588
Labels
difficulty:hard feature new product features that weren't there before

Comments

@huumn
Copy link
Member

huumn commented Oct 23, 2023

For anyone interested in playing more with fees.

Basically we'll want to use something like Damerau–Levenshtein distance such that the cost of a nym is inversely proportional to this distance.

Something like cost = 100000/10^(d-1). Anything where cost < 1 is free.

Additional requirements:

  1. communicate why one nym is more expensive similar to the way we have a little info receipt on post/comment fee escalation
  2. on sign up, nyms will need to be randomly assigned if cost > 1 for things like their twitter handle or email username

An optional requirement is making character substitutions where the substitute is visually similar have a distance <1. Also character insertions, where they are the same or visually similar to their neighbor <1.

@huumn huumn added the feature new product features that weren't there before label Oct 23, 2023
@huumn
Copy link
Member Author

huumn commented Oct 24, 2023

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.

@SatsAllDay
Copy link
Contributor

SatsAllDay commented Oct 24, 2023

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

@huumn
Copy link
Member Author

huumn commented Oct 25, 2023

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.

@SatsAllDay
Copy link
Contributor

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

@SatsAllDay SatsAllDay linked a pull request Oct 25, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
difficulty:hard feature new product features that weren't there before
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants