Basically petnames change the addressing architecture from “one global mapping” to “many local mappings.” This means that petnames cannot be used as shared identifiers; you use a global UUID when you need to identify information between users. There are some contexts where this works great (the phone address book) and some where it doesn’t (Web URLs). In effect, if I wanted to drop a URL in this comment, the petname model requires that I use the UUID. You can share petnames with each other to help people, and you could publish petnames and do searches (but this creates trust questions - how do we verify a pet name is accurate?).
It may be an entirely suitable approach, but it basically means there are no global short names. I can’t tell you Im at pfrazee dot com if there’s no global dot com registry.
> In effect, if I wanted to drop a URL in this comment, the petname model requires that I use the UUID.
Yes... or, not at all, depending on how you want to look at it. To use their phone book example, if I want to call my dad, I look up "dad", and I call him. I don't use his phone number (although obviously down in the internals of my phone it's going to use his phone number).
If you had a local mapping for a web site saved as "coolsite", you might post a link here on HN as "web://coolsite". Your browser would take care of translating that into a UUID under the covers, so the actual post would contain the UUID. When I read the post, though, I would probably see the link as "web://@pfraze => coolsite" (obviously your browser would need to post some metadata for that to happen - similar to how you can include a name with an email address) or if I already have the site in my local mapping I might see it as "web://thatawesomesite", or whatever name I'd chosen. Or perhaps my browser would go to something like DNS to reverse lookup the UUID.
This unfortunately only works in situations where rich text is available that can hide the UUID, which is not the case for HN. The person you replied to is correct: they cannot share the URL literally in that comment, without using the UUID visible to all.
Maybe... But maybe not. If the browser was the one with support for pet names, the browser could see the UUID URI and replace it transparently for you. Would we want the browser to transparently replace a URI in plain text, even outside an anchor tag? Maybe, maybe not - this is a good question. Maybe it would pop up the pet name in a popover if you hover on the URI? Or maybe we'd have some special markdown syntax for these links that has the URI, a suggested pet name for people who don't have one, and a link text (since markdown URIs at the end of a post are pretty much how we roll here on HN today anyways).
I wouldn't try to think about this as "What if we implemented a browser plugin that supported this?" Instead, think about if this was "the standard". Imagine a world where there was excellent support for it in all software that we use, and browsers and/or sites would find ways to make it transparent and friendly. Like, what if VS Code made it so when you hovered over a URI in a piece of code, it would look it up in your local pet name database, and show it in a popover? If this were just "the way things are done", then you'd never put up with crappy software that showed you the UUID. It would be like web sites that don't let you highlight or copy text - software that didn't handle naming resources correctly would be obnoxious software you'd hate to use.
Right, if we're talking about what this could be like then it's instructive to consider what a client would look like that supported this natively. For example, we might have a "petname" tag that a browser could use to display a petname link like so:
The browser would then display this in the same way mentioned in the OP; if you already have an entry locally it shows your local name, otherwise it shows the proposed name and marks it as such.
so if I wanted to share a document about how much water we need in total per day, I could just share you the complete url... or at least that's what I was thinking earlier. As long as I don't have to type it by hand, it should be ok, right?
my rough estimate calculation if anyone is interested, a cube that is about one kilometer and half (under a mile) on each side is enough water for all the people in the world for a day.
So instead of having one global registry you have many local registries. If registries are also identified by UUID then you say pfraze dot com in the <registry uuid> registry. I like this because then you can have registries that correspond 1-1 with other real-life things that can be internally consistent without having to worry about global uniqueness, like a registry of all registered businesses in a state, or all trademarks, etc.
The next step is to create a system for "peering agreements" between registries, or meta-registries.
You can, but any shared address book needs to have a very clear scope of applicability. Basically: any users that are communicating need to either share the same registry, or have some clear indication that they aren't in order to avoid significant mishaps. I'm not totally sure how you accomplish that.
<del>The federated approach would be the same way that we distinguish cooluser@gmail.com from cooluser@proton.me; in this case, the server part would just determine who you're asking to map cooluser to a UUID.</del>
Actually, this is handled pretty clearly in the example article.
A quick Google found "The .com and .net TLDs had a combined total of 174.7 million domain name registrations in the domain name base3 at the end of the first quarter of 2022" Twelve digits covers 40bits or 5bytes and should have more than enough space for all DNS entries.
The replacement for the web will have secure identifiers instead of "URLs", and the GUI will simply replace them with whatever nickname you gave, and all programs on your OS will share the same registry. Or I guess we'll just have another 40 years of misconceived ideas first, it's hard to predict.
Sure, but I'd offer an observation: you typically aren't typing in the URLs people link in comments here anyway! You just click the link and your browser takes you there. This works just as well for a human-readable name as it does for a UUID.
I'm looking forward for the comments about this. I discovered/read about "pet names" a while ago, but I could not understand very well what problem they're trying to solve, and if they solve it.
Petnames try to solve a trilemma known as Zooko's triangle.
A naming system that is both permissionless and globally unique will tend towards unreadable names. You'll see lots of Sybil attacks on these systems, with botnets squatting any decent name.
For DNS, you have many governance bodies that act as gatekeepers for domain registration. Repository hosts like GitHub avoid Zooko's triangle by having namespaces, and an appeal process if someone is squatting your trademark. Crates.io on Rust doesn't allow automated crate creation.
In many cases, naming systems are not permissionless, and gatekept by a central entity. Once you open the floodgates of permissionless-ness, you're dealing with a hostile environment that's difficult to control.
Petnames are one solution to this issue. Others are Handshake, Namecoin and ENS
The proper way to connect to a service on the internet after the 70s when crypto was invented, is to connect by public key or hash thereof. Instead of a bloated insecure HTTPS stack, your code just connects and checks against the public key which was used as the address (actual implementation details like finding the IP address or routing over an overlay network is done automatically with something like a DHT).
The second piece to this is how the GUI works. Instead of showing long bit strings or hex encoding them in some pointless way, it allows you to assign names to these addresses as you come across them. When you see the address in some other page it will show up with the name you assigned and so you will recognize it.
A key point to this is that HTTPS does not actually cause you to know you are using the right domain name. Aside from the fact that HTTPS is untrustworthy due to the CA model, mybrand.com or mybrand.net or one of the other infinite number of legitimate sounding things could all be the correct domain for some brand, you would never know unless someone previously introduced you to the right domain name. Since you had to get it from somewhere, you may as well have received the public key at that point, which could be encoded in a QR code, or, on the internet, which is the main use case of petnames, trivially included as a link in some web 8.0[1] page or chat where you first heard of the brand.
1. I guess it will take them 6 more tries to get this right.
Strong agree. There is a massively undersold feature of IPFS, p2p streams, which do exactly this. We use it extensively in Peergos to sent http requests to a public key. It has stunning UX as well, not having to worry about changing IP addresses etc. This makes it easy to have zero dependency on DNS or the TLS certificate authorities.
In essence the anchor text becomes the petname and is human readable while the href points to the URL of the resource referenced by the link described by the petname.
If you want a name authority, use URLs. What you alias them to is up to you since only you use the alias. If you need the alias also to be globally unique, tough luck! Use URLs there as well (or invent new naming schemes and try to get them adopted).
This happy path seems pretty nice, but I feel like there’s lots of room for attacks of various types, anyone aware of pre-existing discussions around possible attacks?
For example would something like a robocaller be able to reconstruct my social graph? What about work/life contacts leaking across boundaries I’d prefer they didn’t?
The article doesn't really go into it, but most real life applications would not share every contact with every other contact. You can imagine a number of different solutions to this problem, but it's mostly a UX issue on how users would be most willing to share their contacts with others. Apps with different approaches could still share data with one another.
A pentane system actually protects you from phishing attacks and you don't really share your pentanes. You can use your petname as a nickname when introducing a key to someone else. One of the most important parts is to have a good UI/UX that does not confuse nicknames with pentanes or allow you to accidentally accept a nickname as pentane that is confusingly close to an already existing petname.
Nicknames are names that you propose using when introducing yourself or someone else. A pet name is the name you assign privately. So Lumberg could be a nickname but your petname might be "dickhead boss". You're free to introduce him to people you know either way you'd like.
This version of petnames is too complicated. You can't get a good petname system without getting rid of broken crap first. Scanning a QR code on a flyer should be the sole introduction point and just lead to a secure communication from then on. Why do I want petnames for phone numbers or other insecure things?
To put it differently, no petname system built on top of unix / web crap will ever be good. Everyone (like posters here) will not understand what they're doing and just write code that breaks it on all layers of the OS and GUIs. Guaranteed if Android starts using petnames more there will just be issues like it copies someone's petnames all over yours, shares the ones you didn't want to share, etc.
Introduce via a uuid represented as hex, psuedo-pronouncable syllables, or a barcode.
Every uuid maps deterministically to an abstract avatar which can't be changed. It can be canonically 64 or 128 bits, but allow the user to see a 32 or even 24 bit visualisation if they please. If identities have significant cost (such as needing to subscribe to a provider or to be embedded in your local social graph) the smaller should suffice even as a default.
Allow saving with whatever name you please to a list or using the target's name for themselves.
Allow sending a contact with metadata including optionally the nickname
Allow lists to be published, and whole lists to be saved as entries.
Don't hide the uuid ever because that's condescending and introduces many vectors for bad things. People learned what phone numbers were, trust them to learn what a UUID is if you stop shifting the sand under them for a minute and hiding what is actually going on at every opportunity.
It may be an entirely suitable approach, but it basically means there are no global short names. I can’t tell you Im at pfrazee dot com if there’s no global dot com registry.
Yes... or, not at all, depending on how you want to look at it. To use their phone book example, if I want to call my dad, I look up "dad", and I call him. I don't use his phone number (although obviously down in the internals of my phone it's going to use his phone number).
If you had a local mapping for a web site saved as "coolsite", you might post a link here on HN as "web://coolsite". Your browser would take care of translating that into a UUID under the covers, so the actual post would contain the UUID. When I read the post, though, I would probably see the link as "web://@pfraze => coolsite" (obviously your browser would need to post some metadata for that to happen - similar to how you can include a name with an email address) or if I already have the site in my local mapping I might see it as "web://thatawesomesite", or whatever name I'd chosen. Or perhaps my browser would go to something like DNS to reverse lookup the UUID.
I wouldn't try to think about this as "What if we implemented a browser plugin that supported this?" Instead, think about if this was "the standard". Imagine a world where there was excellent support for it in all software that we use, and browsers and/or sites would find ways to make it transparent and friendly. Like, what if VS Code made it so when you hovered over a URI in a piece of code, it would look it up in your local pet name database, and show it in a popover? If this were just "the way things are done", then you'd never put up with crappy software that showed you the UUID. It would be like web sites that don't let you highlight or copy text - software that didn't handle naming resources correctly would be obnoxious software you'd hate to use.
Previously, on HN (just this morning, still on the front page) https://news.ycombinator.com/item?id=32493946
so if I wanted to share a document about how much water we need in total per day, I could just share you the complete url... or at least that's what I was thinking earlier. As long as I don't have to type it by hand, it should be ok, right?
https://numpad.io?#text/O4ewTgNgJg+gDiOBXCBDALgSxAOwAQC8eA7A...
my rough estimate calculation if anyone is interested, a cube that is about one kilometer and half (under a mile) on each side is enough water for all the people in the world for a day.
The next step is to create a system for "peering agreements" between registries, or meta-registries.
Actually, this is handled pretty clearly in the example article.
A quick Google found "The .com and .net TLDs had a combined total of 174.7 million domain name registrations in the domain name base3 at the end of the first quarter of 2022" Twelve digits covers 40bits or 5bytes and should have more than enough space for all DNS entries.
Could you drop the petname and let the clients resolve it via the UUID of the Hacker News website?
Edit: I believe the article calls this "edge names".
A naming system that is both permissionless and globally unique will tend towards unreadable names. You'll see lots of Sybil attacks on these systems, with botnets squatting any decent name.
For DNS, you have many governance bodies that act as gatekeepers for domain registration. Repository hosts like GitHub avoid Zooko's triangle by having namespaces, and an appeal process if someone is squatting your trademark. Crates.io on Rust doesn't allow automated crate creation.
In many cases, naming systems are not permissionless, and gatekept by a central entity. Once you open the floodgates of permissionless-ness, you're dealing with a hostile environment that's difficult to control.
Petnames are one solution to this issue. Others are Handshake, Namecoin and ENS
The second piece to this is how the GUI works. Instead of showing long bit strings or hex encoding them in some pointless way, it allows you to assign names to these addresses as you come across them. When you see the address in some other page it will show up with the name you assigned and so you will recognize it.
A key point to this is that HTTPS does not actually cause you to know you are using the right domain name. Aside from the fact that HTTPS is untrustworthy due to the CA model, mybrand.com or mybrand.net or one of the other infinite number of legitimate sounding things could all be the correct domain for some brand, you would never know unless someone previously introduced you to the right domain name. Since you had to get it from somewhere, you may as well have received the public key at that point, which could be encoded in a QR code, or, on the internet, which is the main use case of petnames, trivially included as a link in some web 8.0[1] page or chat where you first heard of the brand.
1. I guess it will take them 6 more tries to get this right.
If you want a name authority, use URLs. What you alias them to is up to you since only you use the alias. If you need the alias also to be globally unique, tough luck! Use URLs there as well (or invent new naming schemes and try to get them adopted).
For example would something like a robocaller be able to reconstruct my social graph? What about work/life contacts leaking across boundaries I’d prefer they didn’t?
http://www.skyhunter.com/marcs/petnames/IntroPetNames.html
A pentane system actually protects you from phishing attacks and you don't really share your pentanes. You can use your petname as a nickname when introducing a key to someone else. One of the most important parts is to have a good UI/UX that does not confuse nicknames with pentanes or allow you to accidentally accept a nickname as pentane that is confusingly close to an already existing petname.
Nicknames are names that you propose using when introducing yourself or someone else. A pet name is the name you assign privately. So Lumberg could be a nickname but your petname might be "dickhead boss". You're free to introduce him to people you know either way you'd like.
To put it differently, no petname system built on top of unix / web crap will ever be good. Everyone (like posters here) will not understand what they're doing and just write code that breaks it on all layers of the OS and GUIs. Guaranteed if Android starts using petnames more there will just be issues like it copies someone's petnames all over yours, shares the ones you didn't want to share, etc.
This claim is unsupported.
If you have created or know of a better version of petnames, I'd love to hear about it.
Every uuid maps deterministically to an abstract avatar which can't be changed. It can be canonically 64 or 128 bits, but allow the user to see a 32 or even 24 bit visualisation if they please. If identities have significant cost (such as needing to subscribe to a provider or to be embedded in your local social graph) the smaller should suffice even as a default.
Allow saving with whatever name you please to a list or using the target's name for themselves.
Allow sending a contact with metadata including optionally the nickname
Allow lists to be published, and whole lists to be saved as entries.
Don't hide the uuid ever because that's condescending and introduces many vectors for bad things. People learned what phone numbers were, trust them to learn what a UUID is if you stop shifting the sand under them for a minute and hiding what is actually going on at every opportunity.