From Names to Namespaces: When the Reader Is a Machine

Transcript

[music] Hi everyone. Um, I'm Jeff and I'm co-founder and CTO of ENS. And today my talk is titled from names to name spaces when the reader is a machine. Um, this is about ENS and the future of naming. So I want to start somewhere that has really nothing to do with blockchains.

You know, the first thing that happens when a baby is born is you give them a name. You don't give them a number and before they can walk or talk, they have a name. Now, why do you do this? Well, try describing someone without it. The guy with the brown hair and the red shirt, but tomorrow he's wearing a blue shirt, and in a decade he might not have any hair. And for a lot of people you talk to online, you've never maybe even seen what they look like. So everything you could describe about a person changes.

Only the name is that the thing that stays put. A name is the only thing about you that survives every change to you. That's not a nice to have. That is literally the whole job of a name. You can keep referring to something about after everything else about it has moved. Now remember that sentence because everything I say for the next 20 minutes is that sentence but applied to things that aren't people yet. Under the hood software doesn't really name things. It it doesn't name things.

It numbers them. Uyu IDs, hashes, hex's unique, random, and unreadable because no human was ever meant to read them. Then blockchain made one of those numbers literally your identity, your money, your reputation, your signature. 0x 7D 2F it's public. It moves money. And one wrong character sends it to somebody else. And we spent the first decade of this industry before Ethereum copying and pasting random numbers of praying.

So in 2017, ENS put a name to the number. Uh, I built the first ENS app that year and it was a web page. Type a name, point at an address, that was the whole product and Nick Johnson designed the protocol and so that's all it really needs to be. I guess most of you know this part, you know, um, names like Vitalic, your name, the name on the wallet. But what I want to talk to you about today isn't what ENS does. It's what a name is about to be for. Because the job of a name has changed the last couple of years. And I don't think most of this room has noticed that yet.

But first, one question that sits underneath everything else. When is a name worth actually having? I think it comes down to two questions. Is it actually yours? Can someone take it off you? And can anyone check it's yours without asking a company? Every naming system today you use fails at least one. And here's three quick examples from the last few years. In 2023, Gene Huang had held X on Twitter for 16 years. In 2023, Elon rebranded and the company took the handle.

In 2021, unis swap didn't actually own uh unis swap.com. It was actually uh owned by someone else and then apparently SPF bought it and pointed it at Sushi Swap. And it took a WIPO panel three and a half months to move it over. and UNISOP only won because it had a trademark and a legal team. Um, and most people in this room have neither. And this September, Meta launched an AI agent called Muse, already holding the Muse handle on X and Instagram. And that handle was actually used by the band Muse for over a decade now. What happened to the name was decided somewhere you couldn't see by someone who wasn't you? a platform

policy, a panel in Geneva, a deal nobody actually published. So, how does ENS deal on those two questions? Is it actually yours? Yes, as long as you keep renewing it, your name is state on Ethereum controlled by your key. There is no button at ENS Labs that reassigns your name that isn't any one anywhere. Trust me, I've looked. I wrote a lot of those contracts. Can anyone check it's yours without asking a company? Yes, every wallet, every explorer, every contract can resolve it without anyone asking. It's just on Ethereum. So, yes and yes. And even if you own say a.com name, it can also be an ES name as well. Same name

but with the onchain half added onto it. Okay, the new part. So, for the last 30 years, naming systems had one job. Translate for humans. The machine used the address. DNS turns google.com into an IP address. And at no point did the resolver, you know, care about what the word Google means. The names was for us, not the machine. But that's over now. The machine reads the name now. And underneath that, something bigger is happening. Agents are becoming economic actors. They hold keys. They spend money. They call services. They rotate credentials. And more and more the other

side of the transaction is a stranger. A service the agent has never used or another agent that has never heard of it. Anything that does business with strangers has to be legible to them. Who is this? Who controls it? What does it allow to do? Where do I reach it? So if you're never your agent never holds a key and never touches money, it doesn't really need any of this. It's an API call. But the moment it holds a key, it needs a name that outlives the key and that a stranger can check. That was true for wallets in 2017 and it's true for agents today. So at ENS, we're not pivoting to AI. We're doing the same job we've always done, which is, you know, naming the things that hold a key.

And reading the name doesn't answer those questions because really words can say anything. The unlock isn't that the machine understands the name. It's that the machine can read the name and resolve what's behind it. Structured answers from state anyone can check. A name used to be a label, but now it's an input. And the input isn't the word, it's what the word resolves to, all the records behind it. Here's my favorite recent example of that. Um, Jack Butcher, the artist behind checks, did a drop only a few days ago in September on X Money. So, there was no mint page. You sent $8 to Jack and your transaction ID became the seed for your artwork. Around 7,000 people did it. Uh, and there were about

25,000 wallets in a day. That part ran on trust. People just sent money to Jack on Twitter. And then the art went on chain. 25,000 wallets were about to receive tokens from a contract that didn't exist yet. And when it does, it will be one more random address. So, how does anyone know which contract is his? Well, he told them in this tweet. deploying shortly will be from visualized value. Don't trust check. Nobody has to recognize the contract address. They just check against the name which which address which name deployed this contract. And that's what I mean by proof, not trust me. A check anyone can do a person, a wallet, an agent without asking anyone. Jack didn't

need us at ENS. And he didn't need a platform. He needed a name everyone already knew was his. So why is one name enough? Why would 25,000 wallets take a name as a check? Well, why do people keep buying Swiss watches, German cars, and Hermes bags? Nobody has expected inspected every part of all these products. They're buying the name on it. Generations of trust carried by a word. And the name outlasts everyone who built it. A started in 1837, made harnesses for horses. Nobody buying a bag today has even met Tierry Hermes. Companies already outlast their founders. Agents may well outlive the people that made them. Keys rotate,

models get swapped, founders move on. That's the red shirt from the start. What remains is the same and everything it has earned. It's the provenence. It's the reputation. It's the trust. And a name just doesn't just hold that trust. It can lend it. Hermes earned its name on harnesses and then lent it to bags. The name at the top gives power, credit, and reputation to everything that lives underneath it. And that's a chain of trust. In the physical world, this is held together by reputation, lawyers, and serial numbers. Onchain, we can hold it together with simple cryptography.

So, here's the question. Jack did this for one contract, but what happens when it's thousands of things, agents, jobs, keys, all acting under your name? Well, that's what the tree is for, and you already use one today. How do you check that someone works at a company today? You know, maybe you're interviewing for a job. You look at their email. If it comes from an atco company.com domain that you you know you believe it because only the company can hand out an atco company.com address when someone leaves the company the company switches the address off and [snorts] you know you never have actually vetted Alice themselves you trusted the domain behind it a subname

on ENS works the same way you know ops.com can only exist because company put it there or authorized someone to it's the chain of trust from a moment ago built with cryptography instead of lawyers. If you know DNS sec, it's the same principle. Every link vouched by the one above it all the way back to the root. Now, do that for thousands of agents. You wouldn't send data to an agent or take data from one if you didn't trust the company behind it. But nobody's going to vet thousands of agents one by one. You vet a handful of roots. Decide once about the company the way you decide about any brand. And trust flows to everything it issues. Every one of

them you can check. Trust the route. Check the rest. It's Jack's check extended down a tree and anyone can do it without asking anyone. Not us, not a platform, not even the company. So when an agent resolves a name, it's asking one or two questions. Identity. Who is this? Who controls it? Where do I reach it? and context. What does the owner of this name want other than that agents want to know? Is it prices, endpoints, terms, policies, publish once and readable by anything that has access to Ethereum?

Here are both in one job. So agents already pay for things right now with X42 and API charges per request and the agent pays in stable points right inside the HTTP call. Tens of thousands of agents do this today. That's how but that's how strangers pay every request upfront. It isn't how companies buy things. Companies buy a plan. So say company has a subscription with a data provider and it runs a research agent that spins up jobs. You don't hand every job the company's keys.

Each job gets its own key thrown away when it's done and a name job.compe. search.compe. The job needs data. It resolves it via data.provider eeth. That's context. The endpoint, the plan it sells, how to call it, and there are no docs or sign up. Your agent can just look it up and it knows what to do. Now, the provider data.provider has a question. Who is this? A fresh key that is a stranger. So, the provider resolves the job's name. That's the identity. This key belongs to this job and it sits under the parent name company.eth E. Then it checks two things. Does company. have have a subscription and and has company.

said its resource agents can use it. Yes. And yes, the job is in. There's no payment, no sign up, no no API key. So strangers pay per request, but names use the company plan. It's the Alice's email. Again, the company pays for the plan, and anyone with an company.com address gets in. Here, anything under research.compe company. ETH does. So when the job's done, its name expires and the key goes in the bin, the next job gets a new key, a new name, and the same plan. And accountability flows up, the provider logs every request against the job's name. So company sees exactly which job was used, and nobody has to ever read the job-fa the UU ID, but it's a UID with a with a

surname, and that surname has meaning. Now, where is this actually today? Well, honestly, the pieces exist today. Subnames, address records, text records. You can publish an endpoint on a price in a name this afternoon. What doesn't exist yet is the convention. Which records an agent reads for identity, which for context, and how a root says which of its names can use what it's pays what it pays for. That's the work. And I would like this room to be part of that. So, look at what that job needed. It needed a stable name. It needed job.comp.res research.compe a route you can verify company.eth a namespace the route can delegate and

state anywhere anyone can resolve which is what ENS does today already. So that's the whole primitive and ENS already has every piece of it. And it's also why we built ENS v2. So if you guys were here yesterday and you heard Kevin he he did a a really great introduction to V2. So I'd recommend going on YouTube to listen to that. Um, but the very high level is V2 is what we would have built in 2017 when we released ENS if we'd known then what we know now. And it takes the primitive from names to name spaces.

In V1, a name was a leaf in one big registry. Um, could the research agents issue its own job? It could, but you'd either have to write your own registar contract or hand the agent far more control than you'd ever want a piece of software to have. But in V2, every name can have its own registry with its own rules and the permissions we built into the name wrapper. If you guys have used ENS before are now roles in the core contracts. So company can give the research agent exactly one power, the ability to register names under research.comp and nothing else. It doesn't have the power to take names back. It doesn't have the right to do anything else. It just can issue those names and every name it issue carries an expiry. So a job names a job's name stops revolving

when the job's done. So what didn't change in ENSV2 uh matters just as much. The the resolvers are all the same. The the interface is pretty much the same and everything that resolves in ENS today keeps resolving. V1 keeps working and upgrading is is optional. It's live on superlia today. So if you guys are hacking on ENS, please please use it and it'll be on mainet very very soon. So delegated issuance and constrained roles are now first class primitives in the protocol and the customer who needs them most isn't a person issuing a few names. It's an agent issuing thousands.

So there are three things you can do today depending on who you are. If you're running agents already, give them names under your own name. It works on main today. you the name is how someone else knows the agent is yours and it means you can swap its key or switch it off without anyone else having to change a thing. If you sell something to agents like an API, a data data or a protocol, put the details I need in your name like your endpoint and the prices and think about selling to the company rather than to the agent specifically. Let one plan cover the names underneath.

And if you build wallets, explorers, or agent frameworks, resolve names whenever you show addresses. Pretty soon, most of the names your software sees won't have been typed by a person. We started with a baby getting a name before it can walk. And over the next 10 years, we're going to name more things than we ever have before. Most of them will never be born. They'll be spun up for one job thousands of times and maybe even gone by the evening. But some will keep running long after the people who made them have moved on. Keys will rotate, models will be replaced, and the tech underneath will change more times

than any one of us can predict. I mean, it's been crazy just the last year by itself. And every one of them will need what that baby got. a name that survives everything else changing and a way for anyone to follow it back to someone they trust without asking us or anyone else. So that's what we're building ENS for. It's not for the next cycle. It's for the next few decades. The machines can read now, so give them names that last. Thank you. [applause]