Thanks for the reply.
Shouldnāt this be completed before the voting starts? No-one actually know what this is going to look like on opensea / looksrare until it is finished and working on goerli.
Is there going to be enough time to complete and test it before the deployment datetime?
Also, have you considered implementing eip-4906?
Well, wrapped names will be a new contract, so new collection I believe on most platforms.
OpenSea and most other places will just show those two new state/expiry traits, for wrapped names.
OpenSea and most other places will likely not show anything for the individual fuse states, as that is a complex object and not just a string/date/number. However, perhaps other platforms more in tune with ENS could show extra information, like ENS.Vision.
EIP-4906 probably doesnāt make sense as the ENS metadata service is not on-chain at all. It is a separate service run by ENS Labs Actually, see below
eip-4906 event tells the marketplace there has been a change and to pull the metadata again from whichever the uri is, (onchain / ipfs / centralised). If a fuse is burned then markets wonāt update unless the metadata is manually refreshed.
Yep, that is right.
There are FusesSet / ExpiryExtended events that are emitted by the wrapper whenever that changes, but not that MetadataUpdate event.
Only ENS specific marketplaces will pick up those events though. Opensea etc most definitely wonāt.
Iād suggest that implementing eip-4906 would be preferable, but maybe as a compromise, if you donāt want to do that you could add the current datetime into the metadata so that user can see when it was last cached?
cc. @jefflau.eth @mdt
I was investigating the process of updating my various contracts to work with the new NameWrapper contracts.
@jefflau.eth mentioned in his initial post under the contract discovery section the process of discovering the ETH registrar controller address and the NameWrapper address using the appropriate interface IDs.
I only realised that Jeff had mentioned the interface IDs after Googling them having created a new tool (Ethereum Interface ID Generator | EthTools.com - Online tools for Ethereum users and developers.) to derive them whilst clarifying the inputs from which they are produced.
So I derived the ID for the new registrar controller, and it matchesā¦
New ETH Registrar Controller - 0x612e8c09 - Ethereum Interface ID Generator | EthTools.com - Online tools for Ethereum users and developers.
But what I am getting for the NameWrapper differs (0x9ce846a0 instead of 0x019a38fe)
NameWrapper - 0x019a38fe - Ethereum Interface ID Generator | EthTools.com - Online tools for Ethereum users and developers.
Iām using the function selectors from the verified contract deployed at https://etherscan.io/address/0xd4416b13d2b3a9abae7acd5d6c2bbdbe25686401#code#F21#L166
I suspect that this is because you are using a subset of the function selectors to generate the interface ID for the wrapper, but in the off chance this is a mistake (identifier from an old version of the contract) I figured Iād post.
Either way, it would be useful to clarify how the IDs are being derived.
Yes, unfortunately our deploy script generated the wrong identifiers, which we only realised after the vote.
Weāve decided to make do with the incorrect identifiers for now, rather than putting the DAO to the trouble of a second vote.
This is a great idea. Even if we go with the eip-4906 option at some point, having a timestamp can serve as a simplified alternative to any other marketplace or project out there.
Edit: Here is the PR; add last request date field to ENS metadata response by mdtanrikulu Ā· Pull Request #155 Ā· ensdomains/ens-metadata-service Ā· GitHub
An update to the subgraph was pushed a few days ago and is currently syncing (currently at 89.8%). The Graph is slow to re-index and thereās not much we can do about that, unfortunately. You can see the pending version here.
As Greg mentioned, weāre still syncing. We had an issue with an earlier sync and with any issues, they need to be restarted from the beginning. The sync is passed where it failed initially and fingers crossed will be synced soon!
I guess that you already know this, but reverse resolution for names does not work on Etherscan that have been registered on the new reverse registrar.
Hereās a transfer from a new set account.
https://etherscan.io/tx/0x6f21d884c2d8f297be39f461afbfe585ff19f1c83198203c26c1960d09f27be4
I guess theyāre doing their own indexing/caching, and they might have the reverse registrar address hard-coded into that process or something.
No issues with the contract, just an Etherscan UI thing looks like.
Yes, I agree. Itās an etherscan issue. Did you want me to reach out to them, or would someone from ENS do it?
The ENS Labs team has been notified, but feel free to reach out yourself as well
Ok, I willā¦ Last time I spoke to them on blockchat, and they got back to me quite quickly so iāll do that again.
edit: Iāve logged a support request with them, Iāll let you know what they say.
It looks like there is some issues with the goerli subgraph at the moment. It shows failed at 99%.
Edit: Looks to be fixed now.
Question:
Are the new contracts going to be ens named, maybe with an ens.eth subdomain? I assume you would do that.
Thaād be very cool!
Yes, this is standard practice for ENS contracts. This is already on the dev teamās todo list 