Public ID's (Discussion)


Unfortunately this will not happen on SAFE. That would require SAFE to be tracking your usage and that is against the concept of SAFE.


Actually, doesn’t every SAFE user have such an ID already? Isn’t there some key or hash that username is mapped to? As I read through a “Self Authentication” whitepaper, I get the feeling that such hash is described there.



Also every ID is actually a 128 bit value. This DNS system maps a readable name to the 128 bit ID value.


Interesting comment @neo, why is this characterized as scammer? Why not entrepreneurial? Is there now rules being crafted to decide who and what is right and wrong. I thought the safenet was the new paradigm for unimpeded internet use and access.

As soon as you start making rules - you can’t stop making rules.

Let the safenet decide and evolve on its own.

I’m not criticizing you at all, just the direction I see this comment taking policy. And the policy should be NO POLICY. :wink:


This is a valid concern, but I think there are better ways to handle it. For example, a browser add-on that flags domains people might know from the www but which have different ownership on SAFE. Such an app could even have a nice business model, charging the internet domain owners for a warning listing. If such scamming happens, I’m sure there will be solutions, and that we don’t need to design the public id system around it.

I get that some people see a universal dns as bad, partly because it’s like the www dns, although IMO that system works very well. My main issue with it is that it isn’t very secure, open to hacking and easily censored. All things which have been solved by the Safenetwork dns hooray :slight_smile:! I don’t like squatting but having a single universal address system, with very memorable names for almost every Web property there is, is a wonderful UX. So I like it, and I’m yet to be convinced that a pet name system can deliver as useful a system for the SAFE Web.


Not really since SAFE doesn’t need to know WHAT the usage is. It just needs to use the fact you did something different than someone else to differentiate you from someone else which is kind of the point of the id hashe. So it could even boil down to something like: if new action occurs then mutate hashe.

But I see your point. An alternative might be some insanely complex randomly generated string gnerated for every new user.

If so then why isn’t it being used as identification the way I suggest to prevent public ID conflicts?


Because it’s an awful user experience. It would be like using IP addresses to get to websites instead of domain names. The whole point of domains / public IDs is that they are memorable, unique/universal addresses.


Unique/universal and memerable are a contradiction in terms. If you want something to be memorable you significantly narrow the selection of words and phrases. Why does every user need to have a unique public ID anymore than everyone needs to have the same name in a phone book? Being assigned a unique ID number isn’t exactly a novel concept. That’s why I suggested creating a unique ID hashe. I don’t really care HOW it’s created just so long as it’s unique to each account and people are quibbling over names or services.


How so? Are we not talking about a unique and memorable name that can be used universally across the SafeNet? Names are already unique to each account aren’t they? You appear to be suggesting removing the memorable from the list of unique, memorable and universal for some reason - what is this reason? Ta :smile:


I believe I already addressed that in earlier posts if you care to read them. But essentially: Public ID squatting is the new Domain squatting. So yes I’m against linking memorable with universal and unique. Something can be unique/universal OR memorable but it becomes problematic when it is required to be both. More to the point memorable names cannot be universal ESPECIALLY on the SAFE network where it will be very difficult to RECLAIM names. Hence the rent or decaying ownership over time solution. Please read the thread next time.


You are unhappy that people will reserve PublicID’s and not use them. This practice is often called “domain squatting” by those unhappy that the name they wanted was unavailable to them when they wanted it, even though nobody seems to have an active site using that name.

However, your proposed solution is to have randomly generated strings, or even some sort of changing hash. I really hate the changing hash thing. It seems like hand wavey, “we’ll work out the details later”, added complexity, that will lead to huge network load and dead URL’s that point to hashes that have changed after the URL was created.

As for the randomly generated strings. You’ll get those. When all the memorable PublicID’s have been used up or “hoarded” by “squatters” (Central Bankers in Australia call old people who save their money, hoarders, by the way) . When all the memorable PublicID’s are gone, you can always generate your random string. So we’ll get there eventually, if that’s what you want. But even then, I can preface my random string with my initials or dogs name, or something to still make it a bit unique. Isn’t the ability to make it at least slightly unique after all the evil squatters have done their worst, still better then starting off with a system that has no uniqueness at all?


Lol…I did maybe browse, rather than properly read, but I just didn’t quite grasp how dropping memorable was a better overall solution, it appears to be solving the smaller problem (name squatting), by sacrificing the solution to the bigger problem (user experience/utility).
We appear to disagree about what is the larger issue.
However, we could maybe adapt your idea to retain the memorable perhaps? I’m just thinking that most users (maybe up to 99%) will probably not be arsed what their name is as long as it is memorable. The issue only appears to affect mainly existing businesses on the clearnet, with some exceptions - surely the sites can be transferred to SafeNet by verifying identity. I’d have thought this was essentially an admin task for some app/group working with Maidsafe (for now, or potentially as a project for a SafeDao idea I had later perhaps? The idea was to remove Maidsafe Foundation responsibilities and give to community over time, create voting, Democracy etc. I’ll post sometime about it maybe (but on final warning again, so might not make it that far…lol))
Anyway…so, about the other 99%, one top of the head solution might be to present a user with a random selection from a large list of different categories to pick say 3 or 4 things from. The categories could be anything like, colour, animal, item of clothing, number for example. You would end up with " RedDuckHat9" or similar, so still memorable. Just thinking…is this your pet name idea and am I about to be reprimanded again? :smile:
Unfortunately, this will still not prevent people name squatting things like “BlueMonkeyTrousers1”…but seems less of an issue. Might be quite fun I thought.:smile:


The random string isn’t for human usage. It’s so the NETWORK can tell one user from another user. I’m not proposing we use random strings as urls or usernames. Why is this so complicated for you? The whole point of all this so we WON’T end up having to use random numbers as usernames or URLS.

@Al_Kafir You can understand the concept of password generation and brute force I presume? Same concept. Memorable are memorable, consist of human readable language and in context to the site being created. That significantly reduces the combinations available.


How about extension numbers? In the same way one phone number can be divided among dozens of employees, so too could a public ID refer to multiple entities. It retains all of the important traits while making squatting fairly difficult.

This I believe solves the vanity issue that underlies this thread. People don’t want to be the other [insert name here]. Companies don’t want to resort to using another name or append unnecessary characters to their name. Large pre established organizations will hesitate or all together avoid migration if their name can’t be represented as they please.

An extension works to mask the compromise that is adding a few numbers or letters for the sake uniqueness. A second address bar to the right of the original would placed to receive the max 5 character string.

IDK just a thought. :sweat_smile:


FYI @Blindsite2k, I don’t understand your suggestions either, and I have read all the posts. I don’t understand why you think a random string is necessary, when every account is already identifiable, so that’s been very confusing. But so have your earlier posts before that. My response to you may have seemed to be missing your point, and I think they were, so I think it would help if you spelled out exactly what you are suggesting and why in one post.


I just did an edit. Also consider that not only are the permeantations for memorable names smaller but also that on safe if there is no way to recycle them theyear will run out faster.

Essentially I think with billions of humans using the net for even more tasks and random websites that people will burn through public IDs REALLY REALLY fast. For all intents and purposes with a finite set of combinations and no recycling the resource will essentially become exhausted.


Aren’t all IDs just a hash to the network anyway, like ID “PhillyBoy” = “4xh5354gyovs82ni525bfu…” on the network

So then there can totally be different apps that map IDs to hashes. Instead of one, then we have the squatting issue

Exactly like DNS petname list providers


I still consider safe net DNS names more akin to memorable IP addresses. At the start people may use these raw names, but I suspect an overlay service which manages demand for names will materialise. When it does, a nice DNS names may be cute, but will not be the main way people revolve locations.


Wow… Several people are really confused about the DNS / Public ID.

Blindsite / whiteoutmashups is right.

Everything starts with RAW format, 235235h2352k3jh5235.

Then we decided how it is handled, on top of that RAW format. In this case, DNS.

To approach to this problem is from two different aspects;

  1. A monopoly universal naming convention (ICANN / Maidsafe / Ethereum solution)


  1. A private competing naming convention (Cellphone / GNU Name system solution)

That’s all there is to it.

Clearly, @happybeing supports the US government monopoly of Postal Service.

While I, and other who supports “no dns” / “petname”, supports the Lysander Spooner private Postal Service.


What I like is a universal memorable naming system. Others can build their own pet name systems too though, I’m not saying you can’t, just that I want to have a universal naming system.

I used the analogy of postal addresses (nothing to do with the US postal service - of which I have no experience) to illustrate the shortcomings of multiple overlapping naming systems.