App.ens.domains is down

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?

2 Likes

The frontend app is also deployed on IPFS and linked to app.ens.eth!

In Brave: http://app.ens.eth/

Other browsers:
https://app.ens.eth.limo/
https://app.ens.eth.link/

This will work in Brave/Opera too:
ipns://app.ens.eth/
ipns://k51qzi5uqu5diwpzjqae01738agaequoptq4pr5e5lzao2is57hqkffpf9r81q

3 Likes

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.

2 Likes

That’s just a Brave browser issue. You can setup Brave to pull ENS records directly from the blockchain by choosing Ethereum in the settings.

image

On that enable screen Brave just needs to show that option as well instead of just defaulting to CloudFlare.

1 Like

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.

2 Likes

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

1 Like

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.

2 Likes

Yes, I am aware of it, since I wrote it :slightly_smiling_face: I am glad you find it useful. It should get implemented in LabDAO workstream soonish as a compute-resource provider.

2 Likes

Yeah. It feels kinda like that …

:wink:

Hilarious right. It’s good tho!

2 Likes

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.

4 Likes