I’ve been struggling with a couple thoughts here when it comes to public names and MPIDs. What I like to call the Paper Napkin Problem can also be referenced elsewhere as the Moving Bus Problem. Namely that global id must be human-memorable in order to be feasible. For instance, if I wish to, non-digitally, make someone aware of my unique persona on the network, what can I write on a paper napkin that I could remember off-hand, or if they saw my name on a moving bus, would they be able to accurately remember it long enough to get home to their computer and look me up?
Most recently I stumbled on this comment by @dirvine:
If this is still intended to be implemented, then would the easiest way to provide my globally unique public name be with a combination of that name and the leading bits? If so, how many leading bits must I provide to ensure that there is no statistical chance of that reference being misinterpreted? If the answer is just the obvious one - the amount that the network checks - would a sufficient reference or advertisement of my own persona (with my 10-string identifier being a123456789) be just:
Applying the Paper Napkin Problem to the DNS system, then I see an alternative.
The unique, unmemorable 32 hex digit in @chrisfostertv initial DNS was this:
He proposed putting a string on top of it. Now my thought is, if a user can be specified as above, why couldn’t a domain name be as well?
There’s no reason to have to remember an unmemorible amount of numbers - only three pseudo random characters have to be remembered - at the end of any domain name, and then the domain name is provably unique.
In order for squatters to have no legitimate claim to a name, it has to reliably map many-to-one. The way I understand the username situation, it provides a many-to-one mapping of the name itself, but it then uses the first three characters of the MPID in place of where (on the existing internet) the TLD is located. So you end up with this:
google.abc
google.ubx
google.ycd
Now I just used the MPID because that’s what the username uses. In reality, we could use any number that is similarly generated and similarly checked by the system for domainname/ID similarity (see @dirvine’s post above.)
Hi, I totally agree with problem statment and I like the suggested solution. What bothers me however is this - on a particularly lucrative names can it happen that the squatters are so active that the system runs out of unique first 3 letters? What then?
Why would people register the same name so many times? Well suppose some unfortunate folks misremember the magic three characters - then they can easily end up on one of the sites set up by evil-minded individuals…
Another scenario - I have registered a name to myself and I want to prevet anybody else having it - then I just need to keep registering it over and over again until the system is out of unique 3 character combinations right?
Uhh…math. First you’d have to have found all of those solutions in the first place. Each of them would have to come from a separate Public Persona. So that’s submitting for a MPID and then hashing it and reading it’s first three characters. You’d then have to resubmit to the network for a new MPID every time it’s not one of the ones you haven’t found yet. Then once you do find one, you have to start all over again for the next Public Persona. This is the exact same problem (but with an extra hash) as the current naming system is going.
Yes, but this is only for the Paper Napkin Test. I only have to remember the site name and the trailing three characters. That’s not so much to ask for - it’s not even one extra word! Also, if there are any other friends who know of that site, use the Petname System! You can submit the Nickname (domain name) to them and see if they have a matching Petname for that Nickname. If not, but they have a similar one, you may trust a group super majority that centers around one agreed-upon name.
Yes, but you’d only be able to do so with a new Public Persona every time. Once again…math. It’s prohibitively (statistically) hard.
EDIT: This thread should have most of the answers you’re looking for.
sorry, I am still working my way to understand your system so could you possibly please elaborate a little on
why is [Public persona] part of the mix?
you want a unique identifier attached to an otherwise non-unique website nickname
these unique bits can come from anywhere, say the public key of the website right?
is it to make squatting more difficult? but account creation is free right?
Surely if you just wanted to link a website to a [Public persona] a statement signed with both website and [Public persona]'s private keys would be enough?
an Evil Minded Individual registers a website under a Lucrative Name - easy first time
the Evil Minded Individual does it again (different 3 char code) - easy second time
…
after many iterations it finally starts becoming difficult - you try a [Public persona] - and get a website name (name.abc) that is already registered - what happens then? you can’t register it right? get a reject?
finally it gets prohibitively expensive to register any more websites under this Lucrative Name - you get rejects all the time
Indeed! However
A. The namespace for [Public Personas] is expected to get crowded too - even if slowly
B. There is nowhere as much drive for a Lucrative Name for a [Public Persona] since trademarks don’t normally hinge on [Public Persona]'s name but more often on a domain name.
C. If you can’t get the name you want for a [Public Persona] it’s less of an issue. Don’t be “John Smith” be “John Smith the Plumber” - easy. Not so for “IBM” “Apple” “Wikipedia”…
Preface: I only assume that this Nickname System will hinder squatting. It is not a preventative system. However it is extensible. Increasing the Verification Code (three characters after the name) to four, or even five characters increases the pool of options exponentially with little to no impact on the Paper Napkin Problem. Keep in mind these are all arguments pertaining to the naming system. So if what we’re debating here is ultimately the scalability and longevity of the SAFE Network, then we got bigger problems than DNS.
To prove ownership of the site, and to discourage transfer of the site per @dirvine:
In regards to Nickname (domain name) transfer, if an entity wished to ‘purchase’ a domain name, they would have to cultivate a new Public Persona that shared the same SHA512 of the Identifier as the existing site admin. This is prohibitively hard. It would be much easier to create a new domain with the same name, but use a new public key for the new Identifier - now the last three characters will be different to the Paper Napkin Problem: the .abc, .123, etc. Also, if it really was a friendly sale, the website would be able to broadcast a (signed) update notifying all of the Petname Systems of the change. To the end user nothing would look different (perhaps maybe a warning message). Only under the hood would the addresses be different (totally new SHA512 of the Identifier + Nickname).
Keep in mind this Nickname System works on the two levels of readability as the DNS system today does. On top, it’s the user-chosen string concatenated with the first three characters of the SHA512 of the Identifier. That actual address - the IP address lookup in the DNS system - will be the SHA512 of the Persona’s Identifier + Nickname.
This leads to being able to say to another user “Go to my location with this Nickname”, and since they already have your Identifier, they can SHA512 that concatenated with the Nickname you give them and receive the unique name of your site. (as it would appear under-the-hood).
Correct, but accounts are restricted to 2 or 3 Public Personas a once. So if you wanted to squat while maintaining all of your personas, you would have to create many different accounts and then register all of the accounts as the admins of their particular site.
I forsee any Public Persona created after the initial one to incur a payment to the network, and then a payment to the network to register a Nickname. While not outlined in my initial write-up, I do believe that would be beneficiary to the network as it would be a source of revenue, while still allowing Secure Access For Everyone. (I got a couple of thoughts about that, but I’ll save them for a later time).
That being said, assuming that both Public Persona and Nickname creations remain free, the only two factors that it employs to slow down squatters are time and processing power, which is not insubstantial.
exactly
Yeah. Plus, if a squatter is attempting to hijack a site, they can use as many Personas as they want to try and get one. You the user get exactly one if you’re trying to link it to your existing Persona. Something I need to think about. Something along the lines of - the more sites there are with the same name, the less reputation that they start out with. But that brings us back to @Seneca’s proposal. I’ll have to work on that.
P.S. Thank you for these talking points. They are really helping me flesh out this idea.
If you need to put ads on a bus just give a link to a page on the regular internet. That page will contain a link with native SAFE address in it. Regular internet with regular DNS is best suited for this task! Let’s turn it into a web of landing pages for SAFE!!
As for the napkin - suppose we manage to make our addresses reasonably short - maybe 16 characters case insensitive like TOR, maybe a little above that. So just pull out the notebook out of your pocket and copy the 16 character address from there! Or from your mobile. Or print it on a business card. Or your t-shirt! Write in permanent marker inside your boot!
For the Paper Napkin Problem, 16, or even a few more would be sufficent for business cards. That’s perfectly acceptable.
And I initially discredited the regular internet landing page, but that may just be the way to go. The initial problem is to have websites being “discovered” by regular people. The ads will get the people onto the safe network. Once they learn how it works, finding things our way will become more natural. I like it!
I can’t help but wonder if the paper napkin problem is even going to be relevant in the near future. I and most of my friends are far more likely to have a smartphone with them than a pencil, so when they’re in a restaurant it’s a lot more effort to write something on a paper napkin than to take out their smartphones and pass each other a link.
Of course the napkin is just an example, but I think this applies almost everywhere. For example, in my neighbourhood there are several billboards that don’t have hyperlinks on them, but QR codes. I think this digitalization of communication isn’t going to stop. Considering that we aim to make SAFE the internet of the future, maybe we shouldn’t be so hung up on globally unique human-memorable ID’s.
tl;dr
The paper napkin problem is a 20th century problem.
I would be sooo happy if we could get rid of globally unique human-memorable ID’s. That means that the Petname System would be all that we need for this to work…
Call it a Petname Sharing System and I’m with you. Regular bookmarks as we know them aren’t going to cut it, links should be share-able in Petname format.
Petname system is definitely interesting and worth much more consideration for sure. It is worth digging deeper into using such a system with the dns we have and seeing if it can work, we can solve the issue of getting keys distributed (by default) so this may prove extremely useful. I have not dug deep enough myself (way too much else on), but this is exactly the reason these questions were asked.
I think rather than endlessly debating this concept, it’d be better if we make a detailed technical design and then either program it or at least visualize it in a mock-up. The ultimate goal of this entire DNS debate is efficient and reliable sharing of information locations.
Edit: Ninja’d by David, creating a RFC is indeed a good idea.
isn’t this pet name system used somehow by facebook? you type the name of the person in the search bar(there are many persons with the same name), and then based on geolocations(?) facebook gives you the suggested persons from which you choose the unique person
