eth.limo is a privacy-preserving ENS gateway, enabling users to access Ethereum-native dApps and content. LIMO represents a shift in dweb adoption by providing an alternative means of accessing ENS resolvable domains.

Check out our recent articles! https://ethlimo.substack.com/p/ethlimo-everything-youve-wanted-to https://ethlimo.substack.com/p/ethlink-is-now-powered-by-ethlimo ✅ eth.limo supports every ENS compatible storage layer! Users can utilize IPFS, Arweave and Swarm contenthashes.

✅ CCIP-Read for L2 and off-chain lookups are also supported!

✅Emoji and unicode domains supported! 😂😂😂.eth.limo

✅ Limo now supports on-demand @ensdomains subdomain certificates! What does this mean? You can now automatically issue a certificate for ENS subdomains without requesting one from us! How does this work? Once you submit an HTTP request for your name (i.e. app.myname.eth. limo), we'll attempt to issue the certificate in the background. Usually this process takes 1-2m and during that time you might need to keep refreshing the page in your browser. Once the certificate has been issued you'll be able to visit your subdomain on eth.limo.

✅ DNS over HTTPS (DoH) Resolver DNS over HTTPS (DoH) resolver. We now offer an easy to use DNS resolver for ENS domains. The DoH resolver can be integrated with applications for native ENS resolution, or even your browser! We feature both JSON and DNS wire format responses with DNSLink support. This means you can configure your local IPFS client to resolve ENS domains directly from us with the following command: ipfs config --json DNS.Resolvers '{"eth.": "https://dns.eth.limo/dns-query"}' For example if you then requested vitalik.eth, a DNS query would be constructed (https://dns.eth.limo/dns-query?name=vitalik.eth&type=TXT) which would return:

dnslink=/ipfs/QmQhCuJqSk9fF58wU58oiaJ1qbZwQ1eQ8mVzNWe7tgLNiD/ Which would instruct your IPFS client to retrieve the CID above. Consult our documentation for implementation details. Documentation

✅ Chauffeur - Run a local infrastructure stack for resolving ENS domains. https://github.com/ethlimo/chauffeur

✅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.

✅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.

✅LIMO takes public gateway services a step further by enforcing strong privacy guarantees such as never logging IP addresses or engaging in TCP fingerprinting. Limo now actively blocks FLoC (Federated Learning of Cohorts). This is a Google developed algorithm that tracks and correlates users based on their browsing history. FLoC enables advanced fingerprinting capabilities and greatly undermines online privacy and anonymity.

Check out our latest substack article - https://ethlimo.substack.com/p/ethlimo-updates-overview-and-a-luxurious

🎉2024 Future endeavors🎉

We’re busy working on the following updates & new features: ▪️Multi-region CDN deployment (better performance and reliability) ▪️ENS resolution manager app ▪️Continued work on ENS native DNS resolver in anticipation of the .eth TLD being welcomed into the ICANN gTLD namespace (limo-web3-dns) ▪️Gateway as a Service implementation of the eth.limo API ▪️Improved IPv6 support ▪️Light client fallback from Alchemy RPC API ▪️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).

Why do we need ETH.LIMO?

✔️Core internet infrastructure is becoming increasingly centralized and as such, several existential threats have emerged that undermine the principles of an decentralized, open and free internet:

✔️Lack of non-commercial infrastructure

✔️Opacity of terms of service agreements and moderation policies

✔️Proliferation of proprietary browser extensions which require centralized services

✔️The erosion of the “commons” and “public space”

✔️Web 3.0 adoption is still nascent

✔️Most browsers cannot natively access ENS/IPFS

For end users, this means a limited selection of poor quality services that increasingly resemble a cable TV package. Accessing the dWeb can be a frustrating experience. For dApp developers, this leads to a limited selection of platforms and services in addition to lost revenue.

The LIMO project brings additional resiliency to dApps by providing an alternative means of access as a public good. As the decentralized web continues to grow, it is imperative that community projects facilitate the transition from Web 2.0 to Web 3.0.

The LIMO project is organized around the following founding principles:

1. Operate ETH.LIMO as a public good.

2. Establish community governance and oversight.

a. Provide support and technical guidance for builders and users.

3. Work towards building a truly decentralized ENS/IPFS gateway service and global CDN.

4. Build a world-class developer platform for dweb sites, including integrated analytics reporting and traffic management deployment tooling for commonly used web2 patterns such as A/B testing, canary and blue/green deployments.

5. A commitment to open source software and the advancement of web3 through education, best practices, evangelism, and public accessibility.

Documentation Discord