Status-react: Change Whisper ID associated with an ENS name

[rachelhamlin]

User Story

As a beta user, I would like to verify my pre-owned ENS names in v1 (multi-account) and update my Whisper ID.

Description

Type: Feature

Summary:

Scenario 1
Right now, you can not change the Whisper ID associated with an ENS name in the Status app. In v1, every user will have a new Whisper ID.

For those who import their old accounts via seed phrase, we will offer the option to verify ownership of the name + update the Whisper ID.

For those who lost their seed phrase, their ENS names will also be lost.

Scenario 2
Users may also own top-level or other .eth subdomain addresses. These users should also be able to bind their new Whisper ID to the address they own, even if it's registered outside of Status. This was reported in more detail here.

Expected behavior

A user can type in their existing name (name.stateofus.eth or name.othersubdomain.eth or name.eth) in the registration flow. Status can confirm if they own it. After signing a transaction, the user can update the Whisper ID to their new one.

Use this screen

But please change the copy to:

Username is owned by you. Continuing will require a transaction to connect the username with your current chat key.

(current _chat_ key, not current key)

Actual behavior

This UI flow exists but requires a copy change and is not yet able to change a user's associated Whisper ID. It assumed the user had the same Whisper ID.

[rachelhamlin]

Note: would be good to fix this issue as part of this work - https://github.com/status-im/status-react/issues/8941

[3esmit]

This would be the flow to update the resolver of user ens name with new pub key:

//load user pubkey, above is my pub key
const pubkey = "0x044f315b6396d7b58e905233c67b3803cbea2af21dece32cc9a82bc95bd465ab30effe6c103f777b68c7db71f79f4ee6a0deec250e9788b317f7e910131a037e4d";

//prepare data, discard first byte (04) and split pubkey in 2 bytes32
const x = "0x" + pubkey.substring(4,64);
const y = "0x" + pubkey.substring(68,64);

//calculate user namehash (valid for any ens name, not only stateofus.eth
const userNode = namehash("3esmit.stateofus.eth");

//load ens root address, above address is valid for mainnet only. 
const ensRootAddress = "0x314159265dD8dbb310642f98f50C066173C1259b"
//loads ens registry contract
const ensRegistry = new web3.eth.Contract(ENSRegistry._jsonInterface, ensRootAddress);

//check if user is owner of ens node
if(await ensRegistry.owner(userNode) != web3.eth.defaultAccount) {
      throw new Exception("ENS name not owned by user");
} 

//load what is the resolver defined on this namehash/node. Note that user can choose an invalid resolver, such as address zero, or one that dont support setPubKey.
const userResolverAddress = await ensRegistry.resolver(userNode).call();
const userResolver = new web3.eth.Contract(Resolver._jsonInterface, userResolverAddress);

//check if user selected resolver supports interface 'setPubKey(bytes32,bytes32,bytes32)'
const methodSig ="0x" + sha3("setPubKey(bytes32,bytes32,bytes32)").substring(0,8);
if(!await userResolver.supportsInterface(methodSig).call()){
      throw new Exception("Resolver don't supports pubkey interface");
}

//send transaction to change the pubkey. 
await userResolver.setPubKey(userNode,x,y).send();

In case user resolver dont supports setPubKey(bytes32,bytes32,bytes32), or is an invalid address (address zero, address with zero codesizedata) the user should be prompted to update the Resolver address first.

Update Resolver:

//above address is a public resolver in mainnet
const newResolver = "0x5FfC014343cd971B7eb70732021E26C35B744cc4";
//calculate user namehash (valid for any ens name, not only stateofus.eth
const userNode = namehash("3esmit.stateofus.eth");

//load ens root address, above address is valid for mainnet only. 
const ensRootAddress = "0x314159265dD8dbb310642f98f50C066173C1259b"
//loads ens registry contract
const ensRegistry = new web3.eth.Contract(ENSRegistry._jsonInterface, ensRootAddress);

//send transaction to change resolver
await ensRegistry.setResolver(userNode, newResolver).send();;

[hesterbruikman]

@3esmit I'm trying a PR build based off of a develop branch dated today, on iOS.

In the following steps I run into what seems like a contract gas estimate issue when re-registering my ENS name. Raising it as I thought this was resolved. If it's resolved in an open PR, please ignore:

1. Recover account with seed phrase
2. Receive new Whisper ID (a.k.a chat key)
3. Go to profile > ENS usernames
4. Enter ENS user name
5. Name is recognized as owned by me
6. Asked to re-register to new Whisper ID
7. TX overview screen appears with validation on Network fee (invalid number)

The validation and error states should be fixed in #9037 This seems like an issue of the ENS contract though. I could change the Network fee manually to 50000 Limit, 5 Gwei price to complete the transaction.

cc @rachelhamlin @andremedeiros @flexsurfer

[3esmit]

The ENS Usernames interface built-in status-react does not compiles with the smart contracts ABI, @hesterbruikman, that's why you get the error.

The interface is trying to register the username again, instead of simply calling Resolver.setPubkey(x,y)

This is what should be done by status-react: https://github.com/status-im/status-react/issues/8853#issuecomment-531423965
The comment explains in codeish way.

@hesterbruikman you can use names.statusnet.eth dapp to update your username using Status.im V1, just browse to it's address, enter your username and update it. You need to have your pubkey in the clipboard because Status.im V1 does not implements Status API to read pubkey, paste it on the proper filed and send transaction.
After updating you can go to your profile and link your username.

[hesterbruikman]

Thanks @3esmit! Glad to see you jump in on Core and Keycard!

Will follow up with @rachelhamlin to see how this fits in Core planning. IMO, we need this to work from profile, as designed.

Instructing our loyal Beta users to re-register and pay (aka only 10SNT) is bad enough. But having to do so by manually copying a url in our underdeveloped browser, after manually copying your current Whisper ID (is this to old ID before upgrading to V1 or the new Whisper ID you receive on recover?) is not acceptable. Especially not given we're introducing this a breaking change and we've opted to simplify identity by removing display names. If you don't, no one will know who you are.

[3esmit]

I believe the ENS Usernames is not finished it, and is good to heads up the team that is important.

I put Core into my priority because of the v1 launch, which is more important at this moment then other research I am doing, but I am happy to be always around, feel free to ping me anytime.

[rachelhamlin]

Instructing our loyal Beta users to re-register and pay (aka only 10SNT) is bad enough.

Ah, just to be clear @hesterbruikman - this is not the intention for this issue. Is that the impression that it gives? Your experience here sounds like a problem to fix in this scope.

A user should be able to reclaim their name for free. @yenda has some insight into how this all works, so will follow up on Monday when he's back in action 😺

Thanks @3esmit for your help in pointing out Resolver.setPubkey(x,y)!

[hesterbruikman]

Ah, just to be clear @hesterbruikman - this is not the intention for this issue. Is that the impression that it gives? Your experience here sounds like a problem to fix in this scope.

Thanks @rachelhamlin the issue described is clear to me. I think it was misaligned expectations. Thought we already had this covered 😬

A user should be able to reclaim their name for free.

The experience I had was the opposite; in order to change the ENS name I needed to register at 10SNT. If I understand @3esmit this is expected behavior when using the 'built-in' ENS usernames interface, until this the status-react ENS username interface calls Resolver.setPubkey(x,y) , to be implemented as part of this issue.

[yenda]

This is just a bug right now @hesterbruikman you are asked to pay 10snt but the transaction will fail because you own it already and you will loose the gas.

It's already fixed in my branch I just need to work on the UI which was not finished

[hesterbruikman]

Hmmm, the transaction was succesful after I manually set gas limit and price. It's added under 'Your usernames'. Regardless, let's follow up next week. Enjoy your vacation!;)

[3esmit]

@hesterbruikman Are you sure it "was succesful"? Seems like it was not, based on the fact that hester.stateofus.eth still returns Beautiful Fuchsia Atlasmoth.
Maybe we have an other issue here aswell regarding that UI don't alerts of failing transaction.

[yenda]

It was not successful, the gas estimation failed because the transaction would have failed, your transaction probably just burned all the gas you manually set and made no changes

There is no point trying to use the native flow right now it is broken (and has always been). What the app shows is just not true because the logic is very basic and considers that a submitted transaction will succeed

[3esmit]

Yeah, it happen exactly what @yenda told:

> eth.getTransactionReceipt("0xeea6ec004e986f97fa5d3672d67ab4db0a1baf0d1f7bb0004b29ec6697d6b913")
{
  blockHash: "0xb08692a8908d0f4b4add77be564acd0b9e4d23a750e0777196534e8677522677",
  blockNumber: 8662783,
  contractAddress: null,
  cumulativeGasUsed: 2799313,
  from: "0x8c4f71b3cf6a76de2cc239a6fa84e1a80e589598",
  gasUsed: 50000,
  logs: [],
  logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  status: "0x0",
  to: "0x744d70fdbe2ba4cf95131626614a1763df805b9e",
  transactionHash: "0xeea6ec004e986f97fa5d3672d67ab4db0a1baf0d1f7bb0004b29ec6697d6b913",
  transactionIndex: 67
}
> eth.getTransaction("0xeea6ec004e986f97fa5d3672d67ab4db0a1baf0d1f7bb0004b29ec6697d6b913")
{
  blockHash: "0xb08692a8908d0f4b4add77be564acd0b9e4d23a750e0777196534e8677522677",
  blockNumber: 8662783,
  from: "0x8c4f71b3cf6a76de2cc239a6fa84e1a80e589598",
  gas: 50000,
  gasPrice: 5000000000,
  hash: "0xeea6ec004e986f97fa5d3672d67ab4db0a1baf0d1f7bb0004b29ec6697d6b913",
  input: "0xcae9ca51000000000000000000000000db5ac1a559b02e12f29fc0ec0e37be8e046def490000000000000000000000000000000000000000000000008ac7230489e8000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000084b82fedbba63c2a4400ec534d8136c3f7900e3f62264db140ee0890254f6e48575a8fa0e50000000000000000000000008c4f71b3cf6a76de2cc239a6fa84e1a80e589598f1ab965a3db6433923ceba0488ff605f230aca4c4c93bb6563c10b700cfdbbed2a364c980b9cf9679f352584d4da44cc01fc1e7257f1d2b80ffff5af64aa129f00000000000000000000000000000000000000000000000000000000",
  nonce: 92,
  r: "0x4f7c9edd1a305812a7e0e917e9d68810cd4b1545a151f100cc9862c05b3dbeb4",
  s: "0x7d06f99d02c60bfd61904fb2dbc088573955c7510cd61190aaf940888e6153da",
  to: "0x744d70fdbe2ba4cf95131626614a1763df805b9e",
  transactionIndex: 67,
  v: "0x25",
  value: 0
}

Notice: status: "0x0"

It should be 0x1.

https://etherscan.io/tx/0xeea6ec004e986f97fa5d3672d67ab4db0a1baf0d1f7bb0004b29ec6697d6b913

[hesterbruikman]

@hesterbruikman Are you sure it "was succesful"? Seems like it was not, based on the fact that hester.stateofus.eth still returns Beautiful Fuchsia Atlasmoth.

Could that be a syncing issue? Below is a screenshot of my seed phrase recovered on a 2nd device, with a new random name and Whisper ID

[3esmit]

Probably you tricked the app to think you registered xD

[yenda]

There is no point trying to use the native flow right now it is broken (and has always been). What the app shows is just not true because the logic is very basic and considers that a submitted transaction will succeed

[yenda]

I dont why my comment above is in bold sorry

[rachelhamlin]

On the bright side, we heard you loud and clear. 📣