Term 3 Grants - Summary

🌱 ENS Ecosystem
2

What is ETH.LIMO?

Simply put eth.limo is an ENS gateway with a strong focus on user privacy and security that enables users to access Ethereum-native dApps and content.

Project Updates

User Growth:

Last year we saw a massive increase in dWebsite growth and adoption with ENS dWebsites growing 116% between 2021 and 2022. Currently eth.limo serves over 17k unique ENS domains and receives on average 1-1.5m requests per day. During the bull market there were days with 4.5m+ requests.

dwebhash#
dwebhash#1464Ă—548 16.1 KB

These dWebsites can be blogs, resumes, dApps and more.

One of the more unique cases was Devcon 6’s treasure hunt where the team deployed clues to Swarm and IPFS registering the hashes in ENS with participants being recommended to use eth.limo.

Larger Project Adoption:

We’re also starting to see larger projects utilizing dWebsites.

One example is kwenta.eth which is a futures exchange with $372m volume to date and one of the most accessed dWebsites with an average of 800k+ requests per day.

Synthetix also recently announced they’re phasing out the Synthetix staking dapp and migrating to staking.synthetix.eth.

These are just a handful of examples as there are many more projects exclusively using .eth dWebsites. Along with this increased growth comes increased support. The eth.limo team is in contact with many projects offering technical assistance and guidance.

Support for Emoji and Unicode Domains

Examples:
https://:alien:punk.eth
https://:joy::joy::joy:.eth
https://:rainbow::rainbow::rainbow:.eth

Storage Protocol Support

The ENS community had been requesting this for a long time and we’re happy to announce the eth.limo gateway now supports resolving these domains!

Support for Swarm and Arweave Contenthashes

The eth.limo gateway now supports every ENS compatible storage layer! IPFS, IPNS, Skynet, Arweave and Swarm.

Chauffeur

We have released a local ENS gateway that supports all of the primary features of eth.limo. Users can additionally benefit from OS wide ENS resolution, not just in the browser. Chauffeur is designed for Linux and allows users to access ENS dWebsites in a fully decentralized manner. More information can be found here: GitHub - ethlimo/chauffeur: Local infrastructure stack for resolving ENS domains

Base32 and Base36 Encoding for IPFS/IPNS

We have updated both the eth.limo gateway and our DNS over HTTPS service to explicitly use Base32 encoding for IPFS CIDs and Base36 for IPNS peer IDs.

HTTP Object Caching

Improving content retrieval times is always a priority for the eth.limo team. After several weeks of careful testing we have fully implemented static content object caching, globally for all eth.limo resolved names. This means that we will cache content retrieved from IPFS and save it for later retrieval. The result being much faster page load times for all static content.

Future Roadmap and Initiatives

Hotcaching

Caching is a big component of the eth.limo architecture and we are always looking for ways to improve it. In its current form, our caching layer will store ENS domain & contenthash pair mappings with a 15m TTL. This is obviously less than desirable as newly deployed content will not be visible to users immediately. In order to alleviate this limitation, we have been working on a “hotcache” solution that will dynamically update our ENS mapping cache in real-time as records are updated on-chain. Initial support will be limited to names using the ENS public resolver. Record updates will be synchronised as they happen, making updated content available in a timely fashion.

Reverse Lookups

Ever wondered if a particular IPFS CID is associated with an ENS name? Immediately following deployment of the Hotcache, we will begin working on a reverse lookup API for ENS domains. This means that you can search for ENS names based on the IPFS CID or contenthash.

Research on HTTP Header Standards for ENS dWebsites

HTTP headers are tricky to get right, even more so in decentralised environments. Certain browser features (like SharedArrayBuffer) can only be used in a “Same-Origin” context, which requires the use of certain server side headers to be returned to the client. With this in mind, we are investigating the best way for users to define their own header and value pairs at the ENS record level. This would be a new standard for ENS HTTP gateways and permit users to fully leverage all available browser features irrespective of how the content is accessed (i.e. gateway or web3 native browsers).

dAppNode Package

We plan to release a dAppNode package that will allow users to run a local instance of the eth.limo service at home. Similar to Chauffeur, a dAppNode deployment has the added benefit of serving all clients on a local network.

URL Fallback Support

We want users to have flexibility with how eth.limo chooses to resolve content. A feature request that we often see is performing a redirect to the value of the com.url record. In the future, eth.limo resolution will eventually look like this:

  • Does contenthash record exist?
    • Yes
      • Serve content
    • No
      • Does the com.url record exist?
        • Yes
          • Redirect
        • No
          • Nimi fallback

Ecosystem Partnerships

We’ve been diligently meeting and collaborating with other ecosystem projects on delivering enhancements for new user onboarding. We believe that tighter integrations and collaboration between ENS ecosystem projects is vital to the success of the protocol and strengthens the reputation of the ENS community. More details will be announced very soon.

Previous Updates
General Documentation
Gateway Basics
DoH Resolver
Using eth.limo with IPFS (Kubo)
Website
Twitter
Discord

Steward Commentary

Without a doubt eth.limo is foundational infrastructure that adds immense value to the ENS ecosystem. Dozens of builders have built on top of eth.limo, creating a virtuous cycle of added utility that could not happen without the tireless work of the eth.limo team.

It is easy to forget that behind the technology there are real people working every day to make sure the service runs smoothly and consistently. The eth.limo team is on-call. All. The. Time. 365/24/7. To date the majority of the work has been done by just two people.

Furthermore, the cost of their infrastructure is not cheap. They run their own nodes. They handle sporadic DDoS attacks, which spike costs due to autoscaling. eth.limo does this free of charge, unfortunately web2 infrastructure providers like to be paid.

Roughly $100k/year is needed to keep eth.limo running. The cost to run web3 infrastructure is generally more than web2. In part this is because the web3 / decentralized works differently. For example, if a user is storing a large video on IPFS, eth.limo has to serve that through the gateway instead of offloading that to Akamai or Cloudflare. There are dozens of other ways that running decentralized infrastructure is more expensive than traditional tech, this is expected.

The DAO approved EP3.1.1 funding request had 85,000 USDC & 10 ETH allocated to eth.limo. Though this is a material amount of funding. This is insufficient given the value eth.limo provides, combined with their costs.

Over the next few months a proposal will be put forth directly to the DAO to fund eth.limo in a more substantial manner. Stay tuned.

The stewards appreciate the eth.limo team and all the work they have done. Thank you for your dedication.

10 Likes