ens-usernames
ens-usernames copied to clipboard
status-im
Build reverse lookup
Issue #46 is blocked by lack of reverse lookup.
Users need the ability to see the names that they've registered. Currently the only solution is for them to write them down or remember every name, then look up the name in the registration flow again to see if it belongs to them.
Reverse look-up will also make it possible to display ENS names by default in chat.
From @bgits:
We don't have a reverse lookup, given an address or contact code get registrations. Most likely the best approach is to build an indexer, a couple approaches possible here including maintaining a REST API to allow such lookups.
I think that the only use case for reverse lookup is for users which want to expose their usernames connected to their address. It could be built a new reverse lookup that uses the hash of public key to find the username aswell, but that's not currently supported by "official" reverse lookup, which deals only with addresses.
For public chats I recommend that the username is provided with message payload for users that want to expose their usernames with the message, and where clients (that explicit want to resolve usernames, as it would be slightly battery consuming) could verify by themselves if the username in payload matches the ENS PublicResolver definition, otherwise hide message.
I think the reason for doing this is so users can see which names they own because they might not remember all the names they registered and would (ASSUMPTION) rather manage the names from a list we populate for them than searching.
I think the ENS DApp can support it, by filter on the owner field of the NewOwner event and then union with namehash on the UsernameOwner event. I think this will likely be slow and power draining to run from the client, it might make sense to store this in the browser storage(not sure if we have access to this inside status) or maintain a small indexer service ourselves.
Quite a few people (anecdotally speaking) asked about how to see their names again in Prague. We also need some means of record-keeping or recovery because if I forget a name—and we don't churn names—that name is delinquently reserved forever.
In the meantime we could add copy to make clear that a user should write down their name.
What are the pros & cons of maintaining an indexer? (-) It's centralized.
For public chats I recommend that the username is provided with message payload for users that want to expose their usernames with the message, and where clients (that explicit want to resolve usernames, as it would be slightly battery consuming) could verify by themselves if the username in payload matches the ENS PublicResolver definition, otherwise hide message.
Yes it is already the case but the name is only accessible once both contacts have accepted each other.
Here the idea is to have any contact displaying the (favorite) ENS name they have registered. Always. So in a public chat you could see this ENS name even for people you are not connected to.
@3esmit Sounds like your idea of having a custom address based reverse lookup is the simplest. Could that be easily be done?
Indexer might be needed for other features but for this one it sounds better to have a dumb solution similar to the regular ENS lookup.
I think the reason for doing this is so users can see which names they own because they might not remember all the names they registered and would (ASSUMPTION) rather manage the names from a list we populate for them than searching.
Yeah I already lost one name I registered and can't remember
Agreed—if there's a simple solution to (item #1) make it possible for usernames to display by default in public chat, then we should do that.
The indexer is worth considering for (item #2) username management.
FYI - I'll be offline for the next two days.
@3esmit could you write up some specs for item #1/address-based reverse lookup? If you have the bandwidth to work on this, that would be really helpful.
To be able to display ENS names in chat by default was a top feature request in Instabug, and will certainly make all of our lives easier at Status, with constant account recovery and loss of contacts on desktop.
Quite a few people (anecdotally speaking) asked about how to see their names again in Prague. We also need some means of record-keeping or recovery because if I forget a name—and we don't churn names—that name is delinquently reserved forever.
In the meantime we could add copy to make clear that a user should write down their name.
What are the pros & cons of maintaining an indexer? (-) It's centralized.
The simplest solution for an indexer is centralized, but it's a read only operation so I think the biggest risk is the data availability if the indexer goes down. You can also make it a sidechain which will be less centralized. It might actually cost more to build and maintain the sidechain then just have a contract for reverse lookups, since reads from the chain are free, this last point brings up a possible use case for SNT, you could create a sidechain that requires users to stake SNT to read from the sidechain.
For issue https://github.com/status-im/ens-usernames/issues/46 we could also store it using indexdb in the browser if it's no wiped when the browser is closed in Status.
@oskarth Is there a use case you would like to use this for?
@bgits That'd be nice too! The main problem I'm referring to is when you switch devices and can't tell who is who / hard to contact person X. I believe either some opt-in decentralized form of reverse lookup or this https://github.com/status-im/ens-usernames/issues/80#issuecomment-436330746 would work
E.g.: I'm in a public chat and see person X typing, I talked to them before but they only have their random name, so can't remember who it is. If I saw bgits.stateofus.eth it'd only leak that info, which could be seen as equivalent to public key (assuming opt in to default public identity).
Atm we're discussing ways that we could accomplish that w/ some user action (e.g. type in your own ENS name, checks address, opt in to default identity) - but it would be so much nicer if we had a look-up option.