Will never use this. Let the legacy surveillance state die. Don't tie your keys to your phone number.
I’m leaning toward this for the hashed phone number that you could optionally share on your profile so that damus could automatically find all your friends. It would really hard to build a rainbow table for this with a high argon2 security parameter.
What do you think nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z, nostr:npub1n0sturny6w9zn2wwexju3m6asu7zh7jnv2jt2kx6tlmfhs7thq0qnflahe, any other mobile nostr devs ? Should we get a NIP going ? nostr:note1q8kxrrtlat9ezh6evwnqce4mhcqnt6xm5k5vn5xqwmmpeuqa0xusuzl6nc
Discussion
This doesn’t tie your key to your phone number
i think it technically does in a reverse search way tho
but i also think that it has utility if you can find a way to do it that is vague enough in its matches to make it a requirement the user scan through a few dozen possible matches, that it isn't completely terrible
ultimately if you are privacy focused you aren't gonna put such a hash on the network, it's for normies with a lower sense of the importance of privacy
This is why I’m trying to come up with a way that makes it computationally infeasible to reverse it.
Range hashes are still on the table, so there would be no exact number
unfortunately i think that's the thing, the less it leaks metadata the more candidates you are gonna turn up, which defeats the purpose
but i do think, regardless, that for building DVMs able to find any kind of data that this kind of cryptography is the way to make it possible for someone with a sufficiently high entropy clue set to match it up to a highly obfuscated data point
broaden your concept of how to generate the match set and balance your expectations with the idea that people who will publish such hashes are maybe putting a bullseye on their backs