ethereum.eth maintenance strategy

[SebastianSupreme]

Is your feature request related to a problem? Please describe.

Since ENS domains are rapidly gaining momentum in the crypto space, we must ensure that we, as Ethereum's number 1 community, stay at the forefront of this new innovative revolution. That is why it saddens me to see that the official ethereum.org ENS domain, namely ethereum.eth, does not adhere to this idea because the content of this domain is deprecated and thus does not live up to the potential that it could have.

Describe the solution you'd like

That is why I propose that we replace the current content hash of the ethereum.eth domain and replace it with an IPNS hash that points to the most recent CIDv1 of the ethereum.org website on IPFS. This would of course entail the necessity to upload the newest version of ethereum.org to IPFS and direct the IPNS pointer towards it each time a change is made but it would only take up a few seconds of time and comes at no further costs.

Describe alternatives you've considered

Alternatively, we could exclude the use of IPNS and insert the newest IPFS hash manually into the ENS content field, but we would have to pay gas fees every time. Thus, it's of no use to us as a long-term solution. Granted, IPNS may operate a bit slowly sometimes but it far outweighs the disadvantage of having to pay gas fees frequently.

Additional context

No response

[github-actions[bot]]

This issue is stale because it has been open 45 days with no activity.

[wackerow]

Resurfacing this... Still a goal to get the site published to IPFS and pin the IPNS content hash to an ENS. We've now migrated to Next.js which has the ability to export a static site for IPFS, but we use plugins such as next-i18next (handling all the different languages) which is not supported in this type of build.

If others have suggestions on an approach here please tag me.

[wackerow]

We're now on a Next.js stack, which has capabilities for a "static export" which can be deployed to IPFS, and linked to an ENS. Problem is our use of i18n in our next.config.js, which is of course critical to our current translation setup.

Error: Specified "i18n" cannot be used with "output: export". See more info here: https://nextjs.org/docs/messages/export-no-i18n

From https://nextjs.org/docs/messages/export-no-i18n, only suggestion is:

Remove i18n from your next.config.js to disable Internationalization

A solution to get static deploys that we can use for an ENS/IPFS is likely going to require some out-of-the-box thinking on ways we could potentially get around these blockers.

Feature is still desired, ideas welcomed

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity.