[RFC] Public Name System: Resolution and RDF

General RFCs
162

There is a bit staleness in the reasoning IMO.

The example that links would be invalidated is not realistic, and the argumentation is not honest if using these unrealistic ones. It just muddles the waters. No one would link safe://example.site, they would of course link safe://example.site+pubkey.
It would always go to the same site, until the owner of the linking site decided something else.

Simplest feasible scenario I see with the proposal is this:
First time access defaults to list of sites.
You then pick which is your preferred default out from the list. It is not likely to change (but if that situation exists, you could choose for that address, to default to current top position). So when you access after that you always go to your chosen site. Popups for changes is so not UX friendly. User can set if he/she wants notification about changes in the list, and there can be a toast or email or whatever.

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.
So first time access, which is the only one different, would be guided by that as well.

Another thing: First-come first-serve (fcfs) does render a number of names permanently inaccessible. IMO names always being accessible to everyone, in perpetuity, is more ‘perpetual web’ than fcfs.

On the other hand, if this is going to use the non human friendly links that much, the power of the friendly address decreases in relation to today. It may very well be the price paid for the benefits. I absolutely see that it could be worth it. It would give a new situation, a new order and considerations different from today.
But I also read some of the resistance as an unwillingness to leave something known for something unknown. It is a bit ironic considering what SAFENetwork is to the current internet. Everyone has their pain point (limit) though. And mind, I myself argue against complete revolution. Somethings are good to keep. But I personally see the proposal from Seneca superior to fcfs. I recommend the antagonists to read it (I read the whole topic yesterday).

Unrealistic I would say. Out of band should always be considered zero friction, because it is out of network control. So anything that can happen out of band, will happen out of band.

Even the good and honourable (said with complete sincerity) Seneca said this:

Without accusing anyone here, I still can’t help but thinking there is a conflict of interest when early adopters are discussing the possibility to remove an advantage from the early adopters. Just want to point it out.

2 Likes
163

This attack is valid regardless. Grab all names and choose not to sell them.

My view is that there is no great solution but that there are ways to mitigate. So it is easy to point out a downside to any particular suggestion. I’m trying to understand both sides and pull together combinations of ideas that mitigate better than not to do them.

In that vein, some earlier ideas seem one way:

  • limit names per account
  • have a cost per account
  • have a cost to transfer account

Try to set these limits so they have minimal impact on regular activities, but increase the costs of abuse (DoS, squatting etc)

I don’t see this as a great solution, I do see the problems with it. We can try to improve it, try to think of other ideas (qdos to @riddim for coming up with one and putting it to the community test!).

This is a hard problem, but that’s also a challenge to everyone :slight_smile:

2 Likes
164

Good points well made @oetyng. I think my biggest concern with any solution is UX. You mention this as an issue, but I think it is a BIG issue. People will take the easy route (eg turn off / use default, or choose the browser fork that appears simple without understanding what this means in practice) so we need to consider the general public’s response to any solution to the whole, including UX and how that can be used to finesse / manipulate users into certain behaviours.

That’s a really tricky one IMO, so my tendency would be to avoid complicating this area - which is indeed why your point about not wanting to leave something known is, while perhaps ironic as you say, also not without foundation. At least we have a lot of data about the known, upsides and downsides.

2 Likes
165

Actually I don’t think anybody tried this solution yet so we don’t know what this results in for ups/downs - people may for example add a curated list of fixed assignments to their browser that makes sure that the publicly known official representations of companies are correct (so like DNS just not limited in your names and easily exchangeable in your account)… Or any other solution that appears and works well

While with once and forever lost/granted names there are pretty well understood problems:

  • loosing access
  • squatting
  • just taking to remove access for others
166

Proof is history. There is a constant stream of domain name contests that the name providers have to deal with daily. Some reach the courts. Enough proof?

The Pet name system or something similar tailored for SAFE is 1000 times better since the pet name registrars/lists I choose will not see changes to who I consider who is.

And there is no major cost to shut out the 99% of the population who cannot afford to keep paying to recover their name.

That happens now if you lose you credentials for hosting or registrar. Some do allow you to prove who you are but some allow registration without ID and so you have nothing.

Its better than pissing off someone and they take your safe name off you simply by paying for the name.

1 Like
167

I beg to differ.

I say there is a great site selling stepping motors and tell my friend to visit safe://steppermotors when I am visiting him one day.

Why would you share safe name site using publickeys when the idea of safename is to make it easy. Otherwise why not just give them the XOR address (same size as public key)

Why have links that can be outdated real quick by including a key

It is very valid to say people will share sites by their name. That is the purpose of a safename after all.

1 Like
168

Too right the attack against this idea is so easy and easier than spamming accounts like happened to the testnet before invites.

People are nasty and since it happens now with domain names (but is much harder) I cannot believe it will not happen to a greater extent since its easy.

Say I get pissed off with my neighbour, so I buy his safename and ruin his online selling business till he buys it back, but I buy it again and since I am richer than him, he cannot afford to keep doing this. Just another way bad neighbours can be bad

A tailored system along the lines of a “pet naming” system would solve the issues without huge expenses and plenty of name losses

2 Likes
169

Only 12 people have voted on the poll. Please take the time to choose the best name for the name resolution that safe will use.

170

How about moving the posts from here to the main forum in the topic where they belong?

You are purposely posting multiple small messages instead of one larger one to push valid arguments out of the window just because you don’t like it and know that you have not enough good arguments to support your points (and started the thing here again so you can expect less people involved in the discussion…) - that is not okay and I think this suggestion is a very valid one and I think there are enough good arguments to start out with it (and maybe step back later on if it really turns out to be problematic)

171

They cannot be outdated because they must link to the right resource - otherwise they are outdated no matter if they include a link or not and are not a link to a destination of your choice but a link to some random resource you cannot know

Scammers can even with first come first serve create websites with typos that trick people, suddenly change where a link leads to if they own it , buy a link from someone else and redirect it (it’s just that in this scenario you consider it a none issue and don’t help people to recognise while the suggested system is well aware of the danger and creates ways to deal with it) - it’s not like “owning a link for sure” would solve the issue of scamming but “being default owner of a link if no other ranking is being considered” doesn’t… It’s just different…

For example - I’m not the owner of the shop but I am redirecting all orders/info to the original shop owner - then when my fake shop has enough traffic I just redirect the safecoin to my account and am gone - no name change involved in pulling off the scenario you describe

We just end up with a (for the rest of time) dead link that the scammer doesn’t care about anymore and therefore looses

Edit: [just assuming no squatting for a second] +the first stepper motor manufacturer entering safe will reserve for himself stepper, steppermotor, stepper-motor, steppers, steppermotors, steppermotor.us, steppermotor.eu, steppermotor.cn,… The second one will get the rest of the usable names and for any following manufacturer this name resolution scheme will remain unusable

172

And you think the default linked content will change its meaning every other day…?

Then make a suggestion for it that resolves the issues you mention here and is easy to use :slight_smile: I like pet name systems too - imho they just don’t come with the additional advantages of the continuous auction system (while sharing the down sides)

Ps: Well… I guess name registration will be the next feature to be implemented in pySafe… And you can be sure there will be a python script running on the following test nets registering the most active forum names +the up to now published names in ‘safe web links’… I won’t let you guys establish a obviously inferior naming system that doesn’t even resolve the issues you mention with the suggested alternative +only generates profit for some of us… If you insist on war you can have it - I have invested way too many hours in this project to have it ruined by just some selfish people that think they are smart and want to chase their own benefits …

Pps: that’s nothing personal btw - it’s just about demonstrating the problem

173

They become outdated because the person never sees the site’s updates is what i meant. I answered in 3 shorter posts because it seemed logical.

Doesn’t mean you idea is good does it. Just shows there is more than one way to attack. But your idea makes it seem more legit since it is the legit name.

No I meant what I said. That the name system is to save people remembering or telling others a name + long pub keys or XOR address like was suggested in the post I replied to.

Already been suggested elsewhere. And I do not know enough about them to make a good post about it. Sorry.

Your idea already has its parallels in the domain naming system with the registrars and people stealing others domain names by abusing the registrar system but since it is harder to do, we don’t see the effects as much. But there have been some real bad cases in the past. But since this is controlled by registrars it doesn’t happen as much now. But to simply buy the name off others is going to see some real bad abuses and like my neighbour example there will be a lot of scenarios where there will be problems. But the biggest is that the poor (99% of people) will have to be satisfied with what others are not interested in taking and they could lose their name years down the track. Not very fair in my mind and worse than name squatting because the name you buy can still be taken off you later. At least with name squatting you know forever that the name you finally buy is yours forever.

1 Like
174

Taking a step back, how could we accommodate competing address resolution solutions? Maybe with a browser plugin system? Or competitors would need to fork their own browser? If it is a messy area with no clear solution, competition is a great way to go.

Perhaps this also ties into the possible need for content curators (like a kid friendly subset of the network for example).

Personally, I like what ENS has done on Ethereum (see lessons learned here). Namely, there was an auction period whenever a new name was registered, and now there is a yearly fee to keep the name. They also have imports of existing clear-web domains via cryptographic proof. Of course given that we don’t have smart contacts this can’t be done on the SAFE network, but someone could do something similar as a SAFE site/business.

3 Likes
175

+1…

Ps: I have a concept for a petname system I’d love to test in the browser too - the only requirement would be that the plugin scheme should be an importable setting (pointing to an xor address where the resolver lies - maybe with additional arguments/settings that should be handed over - when the scheme you want to use is ready for production it can be uploaded as immutable and you know that the systematics won’t change)

… Maidsafe wouldn’t even need to implement something fancy - they can just go with first come first serve - but as external resolver that is the default setting - and people wanting a different resolver can write one of their own and change the setting (the resolver code can be loaded on startup and it being an external module from the safe network wouldn’t slow down any request later on)

3 Likes
176

You’re not responding to what I wrote. Did you read the post thoroughly?
Noone would link the friendly name, they would link the direct address. (+pubkey is implementation detail, mentioned in original topic, don’t get stuck on that, could be version, like so safe://example.site?v=23. There’s nothing getting outdated there.).
So, no links on sites - which is what you talked about first - would be invalidated. They would always lead to the intended site.

And also I wrote in my post that this diminishes the power of the friendly name.
However your scenario that you visit a friend and will try share the site by saying the friendly name, is just contrived. You’d of course talk about it, knowing how it works you pick up your phones and you just swipe the (direct) address over to your friend.

Proof of what?

There would be no change to who you consider who, if that simple feat I mentioned in my post was used. Why argue against something which would not happen with such simple measures taken?

This is actually a hybrid with pet name system, which is established already in the original topic Seneca started in 2015.

These examples are like if no-one new anything about the system.
Look, you can get the equivalent of First-come first-serve (fcfs) by this:
Type in safe://example.site?v=0, and you will go to the very first site ever created at the friendly name.
So there’s just one simple rule to remember: Adding ?v=0 and you will get to your first site. So if you feel you want to be protected against bad neighbors and other saboteurs, you just put that in your marketing material.

You might say, “oh but how convenient is ?v=2847452637588584 ?”
First of all: anyone beyond v=0 would with fcfs never even have that specific friendly name, so it’s certainly closer to having it, than not at all (which is the alternative with fcfs). Then it’s up to you, if you really want safe://google.com, to decide if you think it’s good enough with v=2847452637588584 or if you’ll just pick another (less popular) friendly name.

So, again: 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…

I’m with you. Let’s setup a way to hog every potentially attractive address on launch, and come up with a way to have it perpetually available to the public.

The first proposal is that they are bought from the network, not current highest payer.
And there is actually an fcfs aspect in that as well, as safe://example.site?v=0 would just in the same way eternally belong to the very first buyer - untill it is sold (wether in network or out of band).
The difference is that you can also get v=1, v=2 and so on, and there would most likely be squatting on those as well. But there would be ways still to use the friendly name for others (albeit with some bigger version, or within a certain trust network or when users default to latest version, and so on…) - something that is absolutely impossible in a pure fcfs system.

Not entirely true, since that’s only through one of the possible ways to access it (defaulting to latest version). If they actually were first, they’d have a very attractive name ([site friendly name]?v=0), and that would be exactly as stable as if it was fcfs, only difference is that “v=0” is appended.

2 Likes
177

Just to clarify @riddim, my comment was about the current DNS for which we have a lot of data and understanding, not a radically different proposal such as yours.

My point there is that it is hard to predict how easy a different system will be to use, what new problems it can introduce etc - in order to point out that there are some good reasons for sticking with what you know and making incremental changes.

I think the rest of this discussion also shows how hard it is to get a reasoned discussion about a radically different proposal, because without objective data, different people have very different idea about how it will perform.

So I’m keeping out of it for now. :slight_smile:

1 Like
178

@oetyng, I did read and responded accordingly but apparently I did a real bad job of explaining and used an example that didn’t convey it all. But its a complex issue and people don’t always do as you want. People will form links the way they do now, what do you expect a lot of ordinary people create their own sites or pages and won’t go searching for which version of the name and which version of the page when link to another’s site. So yes your idea may be able to resolve correctly, but people won’t do it as often as you imagine. Its quite a bit of jumping through hoops just to link to a friend’s site, looking up the version numbers of site and page and perhaps keys too. [BTW: people insert links in comments and that is also another avenue for issues of no version numbers being added]

I think I will too. :upside_down_face:

1 Like
179

I’m thinking along the lines @rob’s thoughts as well, if the proposal is then to have the browser/resolver to fetch by default ?v=0, this brings other problems which are all UX problems. I can think of a few scenarios which to me sound to contradict completely the whole point of having friendly names:

  1. Basic case is the example given by Rob about people needing to now understand that something which is within the same domain, it’s actually shared by different agents/people, as it depends on some part of the URL which was always and will be for long time expected to be some query/param to the content targetted, so sharing links with v=X will lead you to a 2nd dimension of friendly names, but still using the traditional URLs, very confusing and risky for people, all UX, nothing techncal. I say risky because…see the next two scenarios
  2. I have my WebID/SAFE-ID safe://bochacoprofile where I publish/link some wallet address to receive payments. I’d do this so it’s easier and safer to share, and people don’t get confused or annoyed by having to type a long safecoin address, safecoin Wallet address, or even perhaps a bitcoin address I link there, why not even a bank account number. But what happens is that now I’ll need to make sure they don’t (or even myself depending on which version I own) make a mistake by either adding any =vX as the funds will go to someone else (if I own the v=0), or if I don’t own v=0 I’ll also need to make sure they (and me when sharing the link) type the correct v=X I own, or again funds go somewhere else. So what was supposed to be a friendly URL to prevent this type of issues it now brings again the same issues.
  3. The same problem as item 2 above, but for private communications. If I share my WebID/SAFE-ID to receive some private and confidential information has the big risk the sender might end up sending the private and confidential message to someone else, remember I can be sharing my PK to receive the message encrypted within the same WebID/SAFE-ID I share.

And these are without considering that depending which app they use, how good its UX is to help them understand which version of a friendly name they are choosing, or even malicious apps that will be created to exploit this.

So for scenarios #2 and #3, any other person can actually own some version and publish also a SAFE-ID with his/her wallet and private messages inbox, awaiting for such mistakes, and receive messages or funds that were not intended for him/her, so guess what, we just created an incentive for squatting versions of friendly names, specially those which may be popular and receive interesting messages, or known to receive big amount of funds.

3 Likes
180

Oh, here I thought that I injected a whole swath of ‘reasoned discussion’ :joy: oh well…
Anyhow, isn’t the point of reasoned discussion to have it between people with ‘very different idea about ’? :wink:

And if you’re waiting for data on a non existent system before discussing it… well that’ll be a long wait :smiling_face:

Bochaco, now that you are the only one that actually counters the counter arguments, prepare for even more counters :smile: I actually had some thoughts regarding your previous posts but let’s see tomorrow (earliest) what I come up with :smiling_face:

1 Like
181

Where precisely were the arguments against name resolution as plugin hidden?

Other possibly preferred resolvers:

  • a resolver that is coupled with a Web of trust and shows the ranking at the same time
  • family friendly resolver
  • resolver that filters out fun
  • resolver that doesn’t use sha256 as base but a different hashing algorithm (because the good names otherwise have been taken immediately after launch)
  • resolver that is managed by a trusted 3rd party
  • resolver with built in spam/scam filter (i guess a resolver should return the website code so it can inject stuff for resolver management/additional information/filtering)

And of course:

  • petname systems with different implementations

I would have thought that enabling people to just use the resolver they like best and use safe the way they prefer would pretty much be in line with the safenet ethos…?

Edit: if you just enable and don’t try to prevent other resolvers being used easily we’ll probably see what people prefer in terms of UX and what is easiest for them…?

Ps: ok @bochaco you had 3 times the same argument - names should be unique and not be an additional trap for doing mistakes

And I register safe://bochacosprofile safe://bochaco.profile safe://bochaco-profile safe://bochacoprofiles safe://bochakoprofile safe://bochacaprofile for points 1-3 the same problem you describe for the auctioning system exists because you need to make sure that your counterpart doesn’t by mistake end up at my fake destination… (point3 - private communication - I guess we are talking about first contact because in a running conversation it’s obviously a none issue)… - so maybe in this case just unlocking your phone and letting the other person scan a qr code containing the xor address of your id would be more comfortable anyway…?
Pps: And for a second think about someone in 5 years of time who wasn’t as lucky as you and who’s name is now bochaco_1997_the_real - I don’t know if you keep track on the number of people living on this planet but I’m very positive not everyone will be able to just use his first/nickname on safe (and there are new little humans born every day :roll_eyes:)

2 Likes