Itās down. I donāt know what are the reasons, and many of the development team is in an Australian/Shanghai/New Zealand timeline so it might take a while. I suppose it might be related to the recent change to exponential curve pricing?
So, who want to talk about funding alternative frontends?
The Frontend going down, and in this manner, means the ābridging mechanismā is broken between the hosted folder/file (Apache ANT (JavaBased)) and the WebPool App (IPFS/IPNS) serving the requests from the NX Resolver (for DNS).
It is exposing the limitations of the technology that is built into different browsers. While, redirecting apps.ens.domains. <ā that means ROOT from āhttps://app.ens.eth.limo.ā could and does help (ā¦ if itās a metatag and that shell crashes?) not all users have Web 3 browsers like: Opera, Brave, or Metamask.
So integration into Web 1 Infrastructure Framework such as DNS, Name Service, OSI, TC(i)P Stack is absolutely necessary for complete network traversal.
That image above is telling the user that they will have to rely on Cloudflareās DNS Name Servers, and they donāt have to be configured to the NSRoot Server the rest of the web uses-they have their own resolution in theory & in practice.
So it means that ultimately ENSā must useful benefit is limited to the route designated by the underlying DNS layer, and to go more in depth, that means that in order for the route to be transmittable to the content it is trying to access, the IPFS store must also reside in a parallel node that does not have a link-state down making the entire framework and purpose of ENS moot and a universal tool.
Thank you for clarifying it for me. I believe you have brought that up previously-and I agree that pulling the records directly from the blockchain IPNS is valid, my concern is the end user and the integration with Web 2 technologies.
Many Web 2 websites donāt have forward integration with the technology, and many Web 3 dApps arenāt working for web 2 backwards compatibility. That is my concern. In my mind, that is limiting the total utility and accessibility of ENS as a technology. It would also be reducing ENSā total foot print in the totality of the technological ecosystem and would further limit users from adopting the technology.
The knowledge is siloed and isnāt shared among ānormalā users-since it will be those users that will be benefiting from this technology.
I agree with you to some extent. ENS is paying SpruceID ~ $250,000 USD/year for backward compatibility of SIWE to onboard web2 companies that can only implement OAuth. So accommodating web2 at the cost of backward compatibility is not alien to ENS, when it is for good reason
Have you seen this from IPNF? Thereās an interesting application of a Web Wide (Universal) Protocol and it is platform agnostic bcL1 or 2 (block chain Layer 1 or 2) Bitcoin or Ethereum.
I bring it up because it is important to make backward compatibility feasible whenever appropriate, and I agree with you on that
I do remember there were some Zero Dayās found with OAuth integration during the early days of onboarding these technologies to Web 2 sites. Iām hoping that the OAuth process can benefit from any advancements SIWE (sign in with eth) may have made.
We are undercutting an entire industry and alienating some potentially useful partnerships, especially from those that work in Legacy database and webapp pool development.
Yes, I am aware of it, since I wrote it I am glad you find it useful. It should get implemented in LabDAO workstream soonish as a compute-resource provider.
Weāre using Surge for hosting, and they had an outage in one of their data centers. Weāll be transitioning to another platform with better guarantees immediately.