There is a collaborative effort between a few teams that are working on Universal Agent Registry, which is mapping all AI agent data one-to-one to ENS profiles.
### 4.2 NameHash Labs
A large engineering effort for over a year to build and launch NameGraph.
World’s largest knowledge graph of names with over 400,000 name collections and more than 21 million names.
Open sourced layers:
App that builds the 400,000 collections.
App that connects all the collections in the Knowledge Graph.
SDK for API calls to NameGraph.
Dev demo app as an example implementation.
First integration in production at Vision platform.
Technical Side of NameGraph has two main components: collections and generators.
Collections: uses Elasticsearch.
Generators: use linguistic strategies and algorithms to create more ideas.
Two more products yet to launch:
ENSAdmin: Another component of the new multi-chain Indexer for ENS.
Smart contracts for a Referral program for ENSV2.
### 4.3 NameStone
Slobo presented an update to the Namestone admin panel
Features include:
Admins: Multiple people can edit names.
Make names public: Toggles the API for privacy.
Edit records: Pre-populated with important records.
Header and status: Added recently.
Namestone supports Sepolia names too.
5. ENSIP Updates
Raffy has a new draft ENSIP that defines a standard way to return empty data or unavailable name in a resolver.
Dialogue around chain-specific addresses in the cross-chain addresses, see more here.
Blockful continuing to integrate ENSIP-20 into ENSjs
Mission: To use ENS names for smart contracts, instead of contract addresses.
This will increase trust and reduce address spoofing.
ENScribe: A contract deployment and naming service that enables users to deploy a contract and create an ENS name/subname for contracts and set it as the primary name.
Supports Sepolia testsnets: Ethereum, Linea, and Base.
Allows users to upload an ABI file and dynamically add parameters.
Helps DAOs and delegates easily understand what’s going on across different communities, and make better, informed decisions.
Major updates:
Onchain proposals support: in addition to offchain proposals, now supports onchian ones… links to Tally and Agora for voting. Gives TL;DRs, summaries, reasons for votes, etc.
Proposals Calendar: overview of all upcoming proposals across all supported DAOs
Chatbot: indexing forum, offchain and onchain proposals and official documents for providing more quality information
API release: others can build on top of the data collected (forum, proposals, etc.)
The ENSv1 protocol has a critical dependency on the ENS subgraph, which receives more than 700 million requests a year.
The subgraph is missing data on more than 90% of ENS names and is incompatible with ENSv2.
ENS Admin
ENSAdmin is a complementary piece of infrastructure related to the ENSNode.
Considering ENSNode is a backend service, there’s a need for a window to look into an ENSNode instance and understand the status of what’s going on there.
It helps developers better understand what’s happening in the ENS protocol to interactively debug and trace what’s happening across registries, registrars, gateways, resolvers, clients, etc.
New ENSIP-21 written by Raffy called Batch Gateway Offchain Lookup Protocol
CCIP read involves a contract reverting, and the client-side library fetches data from a sub URL and feeds it back into the contract.
A primary user of this is the Universal Resolver, which aids in ENS resolution and is tied into the batch gateway because it needs to make multiple resolutions.
The current CCIP read standard requires sequential processing of URLs, which involves reverting and waiting for each URL.
ENS created the batch gateway for the Universal Resolver to resolve multiple URLs in parallel as a single CCIP read process.
ENSIP-21 standardizes the batch gateway functionality, which was initially codified in the Universal Resolver contract.
The standard specifies how to transform multiple offchain lookups into a request for the batch gateway, which then returns the results.
The standardized batch gateway provides privacy and faster ENS resolutions for users of the Universal Resolver with popular Web3 frameworks.
It also offers a solution for fault tolerance in CCIP read by transforming requests with multiple URLs into batch gateway requests, preventing failures due to server errors.
A local batch gateway will never fail unless there are Internet issues.
4. Space for Service Providers
1. Blockful
Presenting next week - working on the new voting UI for SPP2.
2. Namehash Labs
ENSNode is the new multi-chain indexer for ENSv2 and Namechain.
Provides a new resolution strategy in ENS.
ENSNode indexes state across multiple chains
In cases where all data is onchain, resolution can be completed in milliseconds.
If information is missing (e.g. a uni.eth subname using an offchain gateway), the ENSNode will dynamically retrieve it and return it asynchronously as server-sent events.
The subgraph has many limitations, and ENSNode breaks through these limitations by allowing custom APIs and not forcing a specific database structure.
Gateways are centralized, and ENSNode promotes decentralization by allowing any app to run its own instance
This eliminates dependencies on third parties.
ENSNode will also work to index offchain names, depending on the provider offering the right APIs.
The value proposition of offchain names is shrinking with the rise of Namechain and other L2s.
5. Open Space for Additional Topics
Feedback on ENS IPs (from Kenya)
Thomas in Kenya is teaching African builders about ENS and has received feedback that the ENS IPs are complicated.
Making it difficult to incentivize new engineers to work with ENS.
Potential solution: complexities can be abstracted away using APIs and frameworks.
A potential solution for simplifying this is from NamehashLabs - ENSAdmin – aiming to make it interactive to see how the protocol works and how practical cases are handled.
They are building a tool where users can choose a strategy and name, and a visualization will be dynamically built.
The goal is to learn through examples and help integrators build mature integrations with ENS.
@lightwalker.eth: exciting standards proposal, exciting because as offchain name provider has more and more names can take a long time to paginate through them
In this standard can just listen to changes and be efficiently indexed
Chose OrbisDB due to decentralized nature of Ceramic network, know who controller of gateways are and can easily verify them
SQL database, easy for developers to write SQL queries
Write any content to the data model
Ceramic network not considered a chain, more like IPFS
@slobo.eth: some customers like psuedo-privacy so not all names should be written somewhere, some customers should start offchain and move onchain, Need to understand from a time stamp perspective which one is canonical and how they change
Need to prevent data collisions
Need to think through edge cases that could get complicated
Broader comment on indexing: Goal is for ENS to be a global identity service, might not be congruent with being super easy to index, need to serve customers of the world and think about what is best for them
Please reach out to @slobo.eth Warpcast l X if you would like to present on a future call
]