Closed Lakatoi closed 3 months ago
Hi, I think this is due to the update to our client. Best option is to reset all your records by using a new password. Are you are using IPNS as storage (Ownerhash
or Recordhash
feature)?
I've set the Recordhash for the name and the Ownerhash for a subname. This issue occurs with both.
I reset the records with a new password, but the same problem persists.
Also, after attempting to change the record and encountering the error message, if I try to update it again, the app won't let me, saying that the record is not in sync. After refreshing, it says that there has been no change.
I've set the Recordhash for the name and the Ownerhash for a subname. This issue occurs with both.
I reset the records with a new password, but the same problem persists.
Also, after attempting to change the record and encountering the error message, if I try to update it again, the app won't let me, saying that the record is not in sync. After refreshing, it says that there has been no change.
I don't know if it's relevant, but when trying to access the IPNS through IPFS returns 500 error.
There is some deep issue with IPNS, as it turns out. Several tests are failing on IPNS side. We'll be debugging this exclusively next week. You can try lite.namesys.xyz
in the meantime?
There is some deep issue with IPNS, as it turns out. Several tests are failing on IPNS side. We'll be debugging this exclusively next week.
Ok, thanks!!
You can try lite.namesys.xyz in the meantime?
Sorry, I also get an error: POST https://ipfs.namesys.xyz:3003/write net::ERR_CONNECTION_REFUSED
@Lakatoi 🙏 sorry for this mix up.. 🖐️ I updated our shared IPFS nodes to match another gateway/project's requirements.. 😬
Lite app's ccip write looks ok.. but during IPFS write and IPNS republish there's more uncaught errors.
https://ccip.namesys.xyz/.well-known/eth/mtorra/address/60.json https://ccip.namesys.xyz/.well-known/eth/mtorra/www/address/60.json
We use that ccip subdomain as secondary/lite web2 gateway but our primary primary IPFS gateway is failing withERR_HTTP2_PROTOCOL_ERROR
, & as per specs that resulting http error/status code must be >= 500 to trigger fallback/secondary gateway during ccip lookup.. & AFAIK such ssl/client side error types are not covered by ERC-3668/fallback specs.
@sshmatrix is after temp fix, but for long run we've to move almost all of our current backend logic to client side and prepare for ENS V2/L2s. We've to rebuild with minimum IPFS/IPNS services and web2/ccip gateways for indexing and fallback. We've few more active tests with MFS/IPLD storages (bit fun experiments @ https://github.com/namesys-eth/notapi-eth ) and better+more IPNS republishing services (https://ipns.dev).
__ @Lakatoi As you're already on github, we've more dev friendly resolver and cli/signer tool..
https://dev3.eth.limo/ || https://www.npmjs.com/package/dev3-eth
As default/demo it's free <github-id>.dev3.eth
subdomain system paired with public
eg, ENS subdomain : https://0xc0de4c0ffee.dev3.eth.limo/ ENS record : https://0xc0de4c0ffee.github.io/.well-known/eth/dev3/0xc0de4c0ffee/contenthash.json
You can then switch your domain.eth's to dev3 resolver, then run function setupYourENS(bytes32 _node, address _signer, string calldata _gateway, string calldata _fallback)
in dev3 resolver once.
https://etherscan.io/address/0x37ca355e75a72F4f467f780916DdF5dD90A46592#writeContract#F9
Dev3 is more open and minimalist, so you can copy paste between sub/domains under same 2LD with same approved signer mtorra.eth => /.well-known/eth/mtorra/address/60.json \<*wildcard>.mtorra.eth => /.well-known/eth/mtorra/\<*>/address/60.json lakatoi.dev3.eth => /.well-known/eth/dev3/lakatoi/address/60.json
we've temp fix in place.. 🙏
For future, we've to allow end users to bring their own extra IPFS pinning & IPNS republishing service as fallback..
When attempting to update any records on app.namesys.xyz, after signing the changes, I encounter the message 'Record Update Failed.' In the console, one can see the error: 'ERROR: Failed to write to CCIP2 backend.