Creating discontinuities is a bad idea for moving users from what they know to someone similar and much better. Everyone understands domain names - every those with very limited tech understanding.
Search cannot work as well for going directly to where you want; and taking us back to lists, is also backward.
Domains align with human’s interest in naming and nouning things. As above there are options for spawning multiple instances of the same domain name, whether that is against the xor or any other unique detail, then that should suit well, those who do want to use domain naming. Those who want to do otherwise, can choose whatever they want too.
A point on link rot: an important difference with Safe is that the destination data doesn’t rot, it’s the link pointing to it that may no longer point to the correct version because it didn’t specify a version causing it to always point to the most recent, which might have changed.
The key difference is that because you have that (non versioned) link which is now pointing to the wrong version of the content, you can always step through the versions and find the correct content.
That’s a big difference with lots of benefits. For example, it becomes a feature in that Safe Search ™ can automatically offer to look through previous versions of a site, so if something has been deleted you can still discover it and access it.
And as @mav says, this can be alleviated by tools which help avoid the issue in the first place. I think that could be very effective, but even where this is not done it’s very different to link rot on the old web - because on the old web the content itself has been lost forever.
Yes a very good point, we perhaps need a way of a link being latest if the format tells us that? Then I suppose somebody could replace latest with unwanted data that was not meant?
Yes easy and insecure seems to trump more difficult (even slightly) and secure.
Linking to a version can be encouraged but I’d expect most links will want to be the latest version… and with the expectation that will evolve along the same lines on the basis of being the same owner.
Very useful elaboration Jim, as usual I have bookmarked your insightful thoughts about the UX.
I was a little confused at the start of the post and think you’ve used Site Title and Site Name for the same thing. If not can you explain Site Name in the original.
To clarify my main concern here where I think the bolded part will not be true, if I embed an image in my page from an NRS that doesn’t belong to me and without a version, then that image is changed by someone else later, viewers on my page will only see the latest version of the image and it will not be easy for them to understand that it is showing an unintended image.
We can’t use dates or relative times between versions to pick the right version from history since versions are not pinned against anything, the stand alone for that data. There’s no way to easily deduce which version of the image would correspond to the time my page was published. eg safe://memefactory/most_popular.jpg would be a potentially troublesome src to use for an image on my page.
Not a big deal, just wanted to illustrate my main concern with rot, which is not ‘click this link and go to a different version’. It’s ‘embed this thing and someone else controls that content’. Same is true for the current way CDNs work though so maybe it’s all a bit so what
It becomes more serious if it’s, say, stylesheets instead of images, since stylesheets can hide arbitrary content without it being obvious that it’s hidden.
I’d expect the opposite. Most links will want to be the latest version when published but in five years they want to link to the version five years ago which is probably not the latest. So specific version, even if currently the latest, will be important much of the time.
Hhm what if the browser would show an overlaid button somewhere on an embedded file showing that it’s not the most recent, you could click on it to change the file to the most recent, and click again to change it back.
Yeah, not really a solution though I’d think it could make it easier, just throwing that thought out there.
It is for me as I’ve already stated, built-in NRS allows effective monopoly control for those who don’t know how to use alternatives. And if finite time to MVP/MVE, then NRS is a waste of time right now anyway.
Search is more important as it’s what really breaks other decentralized systems, e.g. openbazaar has such a terrible search you can’t find most products people (like myself) have listed there. Same is true in general for Tor and others. Search is a hard problem, so would be GREAT if Maidsafe would invest any spare energy before MVP/MVE to conquering it.
EDIT: also for those who think, well names are easier than search anyway … I’ve news for you, google and facebook and twitter etc., are NOT going to be using Safe … seriously, I’ll eat my hat if they do. So what is it that you are going to be typing in anyway? Search is what is really important and critical in both the short run and long run.
Monopoly in what sense? I mean, I have monopoly control over my mobile phone number, and my own face, but that’s not so much of a big deal is it? Because there are other elements to my identity that allow people with the same name, or very similar characteristics to be differentiated, yet unique at the same time. As a twin, I know this well.
Again, these two things are complimentary, but serve slightly different functions. NRS gives you a readable, typeable, communicable way to get to a specific bit of information, and also a way to differentiate it from other bits of information, in a form that human brains are used to deciphering.
Search is a way to find a specific bit of information if you don’t know it’s location.
I mean, lets think about what things might look and how useful they might be like if we only invested in search and not an NRS—nor any of the other elements I’ve talked about—via a wee example.
I bump into my friend John Smith in the street. He’s in a rush, but keen for me to contact him on his new Safe app.
“But how can I message you?” I as he jumps in the taxi.
“You’ll have to searrrrrrch!” He yells as the taxi pulls away.
Alternatively, he could just yell “I’m @realJohnSmith, message me!” and cut out all that unnecessary faff.
You also have to remember all the other stuff we’ll be missing out on with out NRS solutions.
Things like tagging people in a run of text on a forum like this, or anywhere on the network. I can just drop @TylerAbeoJordan in any comments or text, and you could see that in your own feed. Doing that with a XOR? Not so easy, not so usable. ** sad UX face **.
Perhaps there is a way we could trial the experience on the forum? Just replace usernames with IP addresses for a day
The simplicity of Safecoin payments also goes out of the window. Quick commands like this aren’t doable…
(Heck, that could even be a voice command. But good luck with getting Siri to handle a XOR address.)
Then there’s things like readable and usable code too. And the also I feel the need to drop a reminder on accessibility too. XOR URLs are just not usable for people with visual impairments that need to use a screen reader… that’s hundreds of millions of people we are cutting out right there.
At the moment the browser just won’t load the content if not versioned IIRC. (This should eventually be baked into the rust resolver ideally).
We need to hold app developers to a high standard on this subject as apps begin to appear to make sure none of the issues outlined become the norm. But link rot is really app layer stuff, and wholly avoidable I think.
The question of which to do of NRS vs Search is not really a question. They are vastly different ideas with search being orders of magnitude more complex. Apples to Planets.
I’d expect the opposite. Most links will want to be the latest version when published but in five years they want to link to the version five years ago
But wouldn’t one use the xorurl directly to link to it? I may have things muddled, but wouldn’t be
original
link NRS → link Map → public blob(v1) (accessible via xorurl)
5 years later
link NRS → link Map → [public blob(v2) (different xorurl), public blob(v1) (old xorurl]
My understanding is that you can update the map, but published blobs are permanent and xorurl addressable. Someone correct me if wrong please, this is hard
Looks to me like you have the correct understanding of how the linking chain works.
We might hope they would but people might use the nrs link since it’s simpler and cleaner, but also prone to changing unexpectedly over time (a side-effect which may not be apparent to the person doing the linking). Sort of like how linking to wikipedia in an essay is prone to having the linked page changed later, the essay writer doesn’t consider that problem at the time and links directly to wikipedia instead of a specific version or archived version.
Presently, an NRS link can contain a ?version identifier, just as an XorUrl can.
So the issue is not necessarily one of nrs vs xorurl, but of versioned-link vs unversioned-link.
As a simple technical measure, the safe-api could reject any SafeUrl without a version identifier, from the get-go. This would effectively force versioning everywhere.
Of course, it is awkward/weird if users have to type a version identifier into browser, so that’s a problem.
Possibly the constraint could be relaxed/removed for urlbar entered strings, but enforced for all URLs in a web-page, for example.
I’m not saying we should do any of this. Just brainstorming a bit, as I think @mav raises good points about web documents sort of losing their cohesiveness over time.
Yes, this may be applied to images too (maybe hover image to show history selection widget?). But unfortunately it doesn’t solve things like scripts and stylesheets. Still, I feel you’ve made a good suggestion here.
Good distinction. To put forward an admittedly weak point, perhaps the simplicity and tidiness of nrs encourages unversioned links, but that’s just me speculating!
can automatically offer to look through previous versions of a site, so if something has been deleted you can still discover it and access it.
