-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Petname System RFC proposal #45
base: master
Are you sure you want to change the base?
Conversation
smacz42
commented
Sep 28, 2015
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. |
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 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 Thank you for your consideration. |
@smacz42 : Sure, we can have a chat over |
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. |
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. |
Let me make one definition here:
@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, 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 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. |
@ustulation please review the latest draft which contains my first attempt at defining the specific implementation of Structured Data for both Petnames and Nicknames. |
… current proposal