[RFC] Public Name System: Resolution and RDF

[oetyng]

Hold on bochaco, I’ll look at this from a couple of levels up first.

@oetyng

There is a bit staleness in the reasoning IMO.

I entered here saying this. After providing a whole pile of reasoning, different nuances, angles and aspects, challenging existing and proposing new material for discussion, it plainly died instead, as antagonistic participants withdrew (barring bochaco). So, that clearly is worse than ‘stale reasoning’ IMO

I’ll continue nonetheless.

The [continuous auction] X [pet name] hybrid (capn) is compared to first-come first-serve (fcfs).

As I stated in previous posts there is an fcfs element to capn since each version can be squatted.
If we look closer on this particular part, we could actually say that there is no difference between safe://example.site?v=23 and safe://example23.site
(Yes, that was an argument against my line, but I guess I’ll need to do that as well now )
So, that alone doesn’t seem to bring much change in any direction.

As was already concluded in OT (original topic from 2015), when defaulting friendly address route to the list of address versions, we actually have more of a decentralised search, than DNS.

So the actual difference is the ability to extend the simple fcfs DNS with different resolution schemes.

Now, the extending as I portrayed it…:

@oetyng

you could set for each address, or for a specific tab in browser, or for the entire browser until you change settings, per browser session, for an identity in the browser:

• Default to first ever created (equivalent to fcfs)
• Default to latest version (this is what you seem to think is only possible option, and keep referring to)
• Default to chosen version (which was accessed via link, or that you picked it from the list of sites under the friendly name. This is akin to pet name system.)
• Default to last one accessed
• Default to the most common in trust network xyz
  etc…

…was never part of any proposal in its entirety (afaik), so that was entirely free styling from me here, composing various bits and pieces with some new ideas.

The main difference is really the ability to choose how we prefer to resolve names. I personally think it’s quite cool with the granularity of this configurability in what I describe above. There is no way of knowing which of these are useful, will be useful, what combinations, in what situations or times. What we can know is that, by doing the above we have extended current internet’s fcfs, and quite probably increased versatility and power of the system.

It’s very hard to increase versatility and power of any system (as to not say impossible) without introducing new risks or requirements of considerations for the user base.

So, if our goal is to come up with anything at all that results in higher versatility and power of the system, we will simply have to accept that. If we don’t, we will have to abstain from changes to current system.

As current system developed in radically different times, and we’ve seen - and continue to see - an increasing richness in the ecosystem it lives in, I would make the assumption that it is likely that we need to look for changes, as to match the increasing richness, with an equal increase in versatility and power of the system.

Now, that doesn’t at all mean the current discussed proposal (capn) is the only one or the preferred one. But it is the one discussed (hrrm, well, was discussed) here. I think any movement forward is quite impossible without sincerely and thoroughly actually exploring the various proposals.

So, that’s the overview for now. Back to details.

[draw]

After reading the discussion above I’m not convinced Riddim’s proposal is ‘obviously better’. Sorry in advance if I repeat or misunderstood something.

From An Introduction to Petname Systems concerning DNS:

DNS strives to make keys that are memorable.

So we are on the ‘keys’ side of the triangle with DNS (with all its problems where people are familiar with, like mimicry). Riddim’s proposal (without the $<number> suffix) is on the ‘Nicknames’ side of the triangle (like what is on top of a google search). That has a lot of implications in behavior. It could seriously confuse people because this proposed system could seem to be a lot like DNS, but it isn’t in some important aspect.
That is a bigger problem to me as the squatting versus who pays the most (auction). An auction is no problem, it is the continuous part that is the problem for me. With DNS you only have to trust the (original) owner of the url for its contents.
If I see somewhere an interesting safe link (or heard it from someone) and I surf to it and get multiple versions: which one do I have to pick? It could be that is obvious most of the times, but possible a good ‘phishing’ opportunity. You could say: take the first one (…$0 or is it …?=v0), but there will be situations this isn’t the correct one. And it won’t be always possible to check the source from the safe link you remembered or written down to determine the correct link (maybe you don’t remember where you picked it up). And for links exchanged digitally, with a qr code etc.: that is not the purpose for memory friendly Safe links (or NickNames): you can use Xor names then.

No harm however to try such a system and prove me wrong.

I think it will evolve in other ways long term which will make the memorable (Safe) names less popular and hence squatting. On 1 hand more exchanging of (Xor) links digitally (or with qr code etc…), on the other hand centralized (a government for example) id check/‘phone book’ systems which you mistrust the least, to search the Xor address of someone or a company and then you make your own pet address with it.

[riddim]

@draw

I’m not convinced Riddim’s proposal is ‘obviously better’.

Sure not - but it’s a superset of fcfs so stepping back and just disabling features doesn’t do harm if it turns out to be problematic so worst case scenario is just having what we have now…

And if maidsafe would make name resolution a plugin in the browser they wouldn’t even need to care or invest any man power (edit: okay not entirely true because it would need to be worked out how to integrate it into the browser - which possibilities need to exist in terms of buttons/user info messages but since all established browsers have an addon eco system and the safe browser needs them because of e.g. Safecoin wallets/Web of trust /search engines anyway it is not a unexpected feature to be implemented in the browser)

[rob]

@riddim

And if maidsafe would make name resolution a plugin in the browser t

This sounds like a reasonable compromise between the naming system and offering people the chance to have better or more accurate names for the sites they use. And the plugin could change the pages (incl search engine) displayed links so it all matches up for the user. I hope this is made @joshuef

But I still see the naming system as useful as an absolute authority of a name to address mapping and the plugin can use either the naming system’s name or absolute address. The naming system allows IoT and other APPs that do not use the browser to have a naming conversion to absolute address

[oetyng]

I’ll once more do some high level thinking. Sorry for going all philosophical, but I think it’s also an important part of analysis.

The “domain” names, and perhaps other things on internet as well, are interestingly similar to commons.
You were talking about land further up, and I had that association even before. My thinking of that is multileveled. Deep down I share native American thinking that no one can own the land. We all care for it, give and take from it. But in today’s world, I am very much a proponent of the rights of ownership - it’s what gives me safety and stability. I can have my little spot in the world, where no-one can bust in, take my house and evict me, because I am protected by laws and I am the owner of this land.

But names on internet is like this weird mix of a physical place and a name. Who can own a name and a physical place forever? Isn’t just the idea of that absurd, given how small a single person is both within our species as well as in time?

So, in the same way there’s this dichotomy with domain names on internet / SAFENetwork.

To me it is not evident that we as a species have fully understood how we should treat digital stuff, what of it that should be publicly owned, and what is privately owned.

I would prefer over fcfs that all domain names were acquired on a decentralised auction on the network.
But that still gives both the absurd forever ownership of something that is arguably public, and advantage to wealthy as well as those who happens to have been born earlier.

I am not sure there even is a satisfactory solution to this. But I certainly think we should try a lot harder than be happy with what we came up with 40 years ago, when things like SAFENetwork was more or less unimaginable.

[happybeing]

@oetyng Philosophy is good - thinking around and from different angles has benefits IMO.

I was thinking about this from scratch again, including the point you make about owning things forever which I hadn’t thought of before.

I arrived at familiar places (ideas, pros, cons) but also a better grasp. So I think the revisiting and reworking that happens in topics like this is useful. I was never saying it wasn’t BTW - just that it is hard to work things out with only our imaginations to guide us and in that realm, without evidence and experience to guide us it’s easy to get things wrong.

I don’t really like the domain name model for the reasons most of us agree, but to date I’ve not seen anything that seems better than that to me in regards to simplicity, familiarity and workability, with all its faults.

I do not though think it is necessarily right for SAFE because our present implementation is different (names don’t expire for example) in ways that mean it too won’t necessarily work as we imagine. I’m not ready to abandon it yet though! It’s still my favourite, ideally with some features to mitigate squatting if we think that’s possible (I’m not even convinced of that yet even though I’m suggesting it). So I am open to alternatives.

One observation which I agree with is that it won’t be the only game in town, and I don’t think Maidsafe need to do anything to ensure this. Resolution happens in the client, so any client or browser fork can have its own naming scheme. And any client can adopt any number of such alternative name resolution schemes.

We might want to encourage it though if we think its a priority, at least by ensuring it can be done with a browser plugin.

Anyway, in some ways the scheme we are debating is only special because it will be supported in the initial official applications, and applications which follow the convention.

This means that I’m less worried about names lasting forever - a new scheme will always be available, and could be adopted widely, leaving old schemes to atrophy.

Where universal permanent links are needed, we will always have the xor addresses, and in time I expect client apps and users will adapt to multiple schemes, with xor as an underlying permanent layer. So I suggest that the most important feature of the initial name resolution scheme may just be to help the transition - by being familiar and easy to adopt. Later things can evolve regardless of it.

This is where it gets hard to predict how things might play out, but a useful analogy might be blockchain forks. So, for example the Doge Naming System , and all manner of schemes with creative quirks , perhaps rentable names, expiring names, etc if there are attractions for such features. I’m not saying there are, but I can imagine there might be for some.

If what I’m saying is true, maybe all we need to do at this stage is ensure that the current naming scheme is fit for purpose. Later, the fact that it is entirely in the hands of clients rather than a centralising body means that there will be alternatives, and battles for users between those backing them.

I can imagine people trying to gain users by offering goodies in the client, emoji names for example, themes for different groups etc.

In some cases we want universality, in others perhaps groups want their own resolver ‘lingo’ that only works for users of their particular protocol, and this could even be restricted to members of the group.

I’m not saying any of these are good ideas. What I’m saying is that we may not need to worry as much as at least I have been doing, about the initial name resolution system. If it performs badly in the long term - ie no decent names left - that creates a pressure for an alternative to be adopted and for clients to add support for alternatives.

[happybeing]

My post immediately above has shifted my thinking on this and other issues.

I now see the main aim in designing these systems as for adoption of and transfer to SAFE Network, and think we should not concern ourselves about the long term.

I’m thinking that what is built on top is out of our hands, and that we need to focus on two things:

• getting the Fundamentals of a decentralised storage and communicative network right (see SAFE Fundamentals)

• mass adoption

What gets built on top of this, including name resolution, will I think evolve regardless of what we start with, in ways that we can’t predict or control.

One analogy is that we’re talking about the area of raising a child (the initial network).

As parents we want to ensure she gets the best physical and mental health, and a good education, but when she leaves home we can’t determine her future.

So from now on I’m going to try to look at what is and isn’t a fundamental, and where things are not fundamental, I suggest we focus on adoption and migration because beyond that we’re being unrealistic and controlling parents!

I don’t think the name resolution system can be constrained whether we want it to be fundamental or not. I think the debate for me then becomes about whether or not doing X helps adoption and migration.

In case of name resolution it leads me to choose simple and familiar because I think that will help adoption and migration. With the knowledge that when the time comes, people will extend and improve on this.

[drehb]

For posterity, linking to @bochaco’s fresh coins idea: https://safenetforum.org/t/fresh-safecoins-from-farmers/28796

It was an interesting and “outside the box” idea to mitigate name squatting. Kudos!

[oetyng]

@happybeing

I now see the main aim in designing these systems as for adoption of and transfer to SAFE Network, and think we should not concern ourselves about the long term.

I’m thinking that what is built on top is out of our hands, and that we need to focus on two things:

• getting the Fundamentals of a decentralised storage and communicative network right (see SAFE Fundamentals)
• mass adoption

You’re so right, and I completely agree. As long as the chosen solution is open for modification / extension.

Network upgrades will get solved somehow, I’m just thinking that it’s not like changing tyres on a moving car - which is bad enough - but on all cars on a racetrack, at the same time, from the sidelines. So would really want to avoid pushing stuff there, if possible.

@happybeing

So from now on I’m going to try to look at what is and isn’t a fundamental, and where things are not fundamental, I suggest we focus on adoption and migration

Me too.

[rob]

Well @joshuef, it seems the vote is favoring “NRS” with 50% of voters.

Mind you it seems Maidsafe devs have not done much voting since only 14 voted so far

[RFC] Public Name System: Resolution and RDF

Here is a Poll. I’ve added 5 extra with new code 1 to 5. I will edit my post to add in any more suggested names and give it a number 1 to 6 poll New names not known when poll made. Poll resets if I try to add them after. So vote for the “new name #” selection in the poll PNS - Public Name System (male member) sns - safe naming system @jlpell XAN - XOR Address Naming SDNS - SAFE Decentralized Naming System Removed since no votes at all PPN - Perpetual Public Name SRR - Safe Resolution R…

[joshuef]

Ufff, you have one week off and stale threads go crazy (great to see!)

Good thread to catch up on. Some things (without having dived into fresh coins or given more than a cursory scan at @Seneca’s olde thread thus far [playing catchup all over today]):

@JimCollinson

What If I just want to create a username to communicate in private with my friends? What if the SafeID is created using unpublished /shared data, and not publicly viewable?

The public name itself will have to be public (barring offering the ability to provide your own naming system). It’s a locator for a document via a publicly accepted standard (sha3(<yourName>)). That document should be readable or we get errors (like, this data is not published/nonexistant etc). But you can reference other data from this document.

The communications don’t have to be public though. Same with email/whatsapp Your address/phone number is public, but you can encrypt the comms.

---

@riddim

that would mean it’s stored in clear text in vaults too

The intention is for all data in vaults to be encrypted on some level I believe. Even public data, the vault owner should not be able to access.

---

@oetyng

I additionally see (with more advanced functionality/apps available) how the list of owners can also be sorted by what your friends (or other people in your chosen network of trust) have chosen as default site.

I think this is a reallllly powerful concept. And I think however we define PNS now, may not be that way forever, or would be customisable down the line. (Which may de fang squatting some).

@drehb

Taking a step back, how could we accommodate competing address resolution solutions? Maybe with a browser plugin system?

Yeh, right now we propose one resolution system. But it could be set up to provide alternate / custom resolvers. And I’d say if that’s popular enough, then it should be included in basic browser functionality. Who are we in the end to prescribe any given DNS system? I view the RFC as an initial recommendation, but I don’t think we could enforce such resource resolution if we wanted to.

@happybeing

One observation which I agree with is that it won’t be the only game in town, and I don’t think Maidsafe need to do anything to ensure this. Resolution happens in the client, so any client or browser fork can have its own naming scheme. And any client can adopt any number of such alternative name resolution schemes.

yep!

[riddim]

@joshuef

The intention is for all data in vaults to be encrypted on some level I believe. Even public data, the vault owner should not be able to access.

since I only need the xor address of the data to get it and no key data is included the data map looks to me that the data map might/will be stored in clear text if you don’t do anything encryption related on the browser side…?
(not entirely sure but this could hint in this direction RFC 55 - Unpublished ImmutableData - #40 by dirvine - RFCs - Safe Network Forum - but I’m on very thin ice here )

@joshuef

Yeh, right now we propose one resolution system. But it could be set up to provide alternate / custom resolvers

Would be super awesome if custom resolvers can be used in the standard browser without needing to fork it - very cool this is something you could live with

[draw]

@joshuef

And I think however we define PNS now, may not be that way forever, or would be customisable down the line.

You’re waiting for the end of the poll to call it something else, still not convinced or trolling?

[joshuef]

@draw

You’re waiting for the end of the poll to call it something else

Yep. [20chars]

[draw]

@rob Any idea when to close the poll officially? A week from now? I don’t think it will get that much more votes than it has now on the dev forum.

[joshuef]

I have to say, putting whatever acronym and resolution system aside for a mo, @JimCollinson’s point re the actual UX of the name of the name is certainly something we need to consider more.

NRS is great. But Choose your name is not really all that clear when getting new folk on board.

@JimCollinson

However, given that they will be the basis of the human readable SafeID address/handle, it is perhaps a mistake to call them Public .

I wouldn’t say it is a mistake to call them public. The initial document accessed has to be public to be part of the system. Private data at a WhateverName is erroneous.

@JimCollinson

Asking a user to create a “Public” name when they only desire to communicate privately (which the system still allows) might be confusing and misleading.

And just to reiterate my point above (as it was smushed inside a bunch of other thoughts), I don’t think this is an issue w/ phone numbers / email shouldn’t be here. It’s just the public way to find your info. How you use that w/r/t private convo apps is something else.

[rob]

@draw

Any idea when to close the poll officially? A week from now?

How about the Poll gets closed on Thursday [June 6th] (Friday Morning my time) after the Dev Update has been posted and I’ve had morning coffee.

It will have been around a week by then

Vote now or change vote if needed here [RFC] Public Name System: Resolution and RDF - #88 by rob

[rob]

@joshuef

I wouldn’t say it is a mistake to call them public. The initial document accessed has to be public to be part of the system

The access to the naming system is public, but to call it a public naming system is like calling

• phone book a “Public Phone Book” (Talking of the paper phone books of history)
• Cinema a “Public Cinema”
• Dictionary a “Public Word Book” Even “Word Definition Book” is better
• Supermarket’s price list a “Public Price List”

When something is inherently public then adding “Public” to the front is senseless and of the same vein as calling “DNS” Domain Name System system OR DNS System. It is doubling up and begs the question where is the Private Naming System

[draw]

@rob

the Poll gets closed on Thursday

To avoid misunderstandings: do you mean next week June 13 or this week June 6?

[rob]

@draw

or this week June 6?

This . . . . . … . .