Petname System RFC proposal

[smacz42]

[ustulation]

hey @smacz42 .. Thanks for your proposal .. While I try to wrap my head round this, could you maybe provide some examples for people to easily get the gist ? It would be very helpful to have that in the RFC in addition to the theory that you have written. Something like for Nickname ABC, the Petname is XYZ etc. and how they are related and how do you want them to fit into our system. Also helpful would be how our Structured Data would contain them and work with overall.

[smacz42]

@ustulation,

Thank you for your reply. I'll draft up some scenarios to exemplify the theory, and attempt to keep them as straightforward as possible.

In regards to how the Petname System would interact with Structured Data, I must admit I'm at somewhat of a disadvantage. Since it is relatively new, I haven't been widely exposed to it, and still have some questions about it. In the forums (going by @smacz) I've been attempting to clarify several points about it without much luck.

My first instinct is that it will work similarly to the safe_dns implementation that is being written. Apart from that, I'm stuck. I'm not sure at what level the Structured Data aspect of the safe_dns crate is implemented at, and how it works with the overall system. There are further hurdles to overcome (symlinking and versioning) when it comes to the actual data object itself, but first I need a solid foundation of how the safe_dns crate functions so that I can present a clearer picture of how I propose to modify the idea behind it.

Would you have any suggestions of where to look for technical details, or perhaps who to contact in regards to either Structured Data or the safe_dns crate?

Thank you for your consideration.

[ustulation]

@smacz42 : Sure, we can have a chat over mumble. It's something we use here to communicate. You will need to download and install the client. This might be a good starting place. Once you do that, configure by entering 178.62.114.234 for address and 64738 for port. You can choose anything for username and label. You should be able to connect to our mumble server. My name is Spandan and you'll find my room there. Just double click to enter it and hopefully i should be there and we can have a chat.

[smacz42]

Thank you very much! I compiled the client successfully (blasted Fedora) and will reach out to you once I can put together my existing knowledge of the matter.

[canndrew]

As an addition to this idea, it might also be an idea to allow people to trade-off the other side of Zooko's square and use globally unique, decentralised, human-readable but inefficient names (a la namecoin). These could be prefixed with their own sigil eg. $paypal. If we added reverse-lookup on this namespace it could be used in place of keys when printing conflicting nicknames (eg. out of Paypal$Paypal and Paypal@155f it's easier to guess which one is legit).

[smacz42]

Let me make one definition here:

• Identifier = Nickname + First X bytes of MPID

@canndrew The reserved character and bytes after it are really only there for one reason, to differentiate two Nicknames that are shown on the same display. I initially hadn't included them in my first draft of this RFC, and only mentioned them once I realized that there may be confusion if two similar Nicknames showed up on one screen.

There are several ways around this, but I chose the one that was most in line with the MaidSafe ecosphere. There could be a different implementation of this same functionality. For instance, if two similar Nicknames were returned for one display, the network could realize this and append, say, (1) to the first Nickname, and (2) to the other. This still provides the same functionality of differentiating similar Nicknames without any non-human readable display.

In fact that was my first idea of how to solve this problem, but then I started questioning how much the network should know about the information being requested. Could it notice two similar Nicknames for one display? What if two displays were present on the computer screen, should the network know about that?

It all became too Orwellian for me, and I decided to default to always attempting to individualize the Nicknames - which is illegal according to the Petname System, but the purpose that it serves is not to indisputably differentiate the two, but only rationally differentiate the two.

The Identifier is not globally unique as there may very well be a similar name with a similar first X bytes of the MPID. Therefore, this should never be used as a definite identifier - only the full Key is globally unique. Any search engine would use this sort of functionality to differentiate Nicknames, not view them as a direct, indisputable unique entity.

It doesn't always have to be shown, and maybe it shouldn't be. It could be confusing as well as frustrating. The goal of the Petname System is to facilitate human-readability, and these do not fit in well with this aim. However, it does serve it's purpose for the time being.

I believe that the system that you described would be well suited to an APP. Entities could be able to choose their own name, as long as it was unique to that search engine/database/whatever. This, however, would require a centralized management of inputs to make sure that any given two are not the same, that they are all unique.

That is starting to look like some kind of DNS system, which is quite able to be built on the Petname System, however, it would be a service, not a built-in functionality. There would be many different ways to go about doing this, however, there are two main problems of which most of the proposals in the forum fall victim to either one or the other.

The first is a problem of "first-come first-served", which enables name squatting. The second is a duplication of names in a single namespace. Both of these issues have been discussed in-depth on the forums, and I would highly recommend that you check out https://safenetwork.io and search for any topic with "DNS" in it's title. Reading just a few will give you a sense of what I'm talking about here with these two problems.

So while I believe it is a good idea, and can even be made more human-friendly, this idea may be better suited for a technology that sits on top of the Petname System, but is not included within it.

Thank you for your consideration.

[smacz42]

@ustulation please review the latest draft which contains my first attempt at defining the specific implementation of Structured Data for both Petnames and Nicknames.