Flexible urls and focus as Resource Locators

Premise: In the absence of servers, we need to make use of what flexibility there is.

Thinking: URLs are intended to be "Resource Locator"s. As an aid to communication, safe://urls can help with focus and discovery.

Idea: If the first element of the url is not ownable, then it become a useful flexibility.

Fallout: It might help stop the domain hogging.

Fallback: If people want the more traditional experience, they could opt for

safe://www.domainname

with the option on the like of

safe://authority/assertingagent
safe://annotation/whatever
safe://comment/xor/UUID
safe://comment/nrs/UUID

this would allow a simple way to know where to expect certain content might land.

For those who do not want it: It is not a catch-all or a requirement, just an option.

Trolling against this would fail. There’s the option that people could abuse this idea but it is predicated on that people want to communicate. What works, is what does conform to simple expectation for some form of url. Obviously people can create blah that is noise but that is another problem for filtering to the user’s preference.

Potentially, a focus of where feedback is put, can assist with consensus. So, might also help with options on filtering… the wisdom of the crowd against urls for example.
safe://comment/url/AgentUUID/feedback

We don’t necessarily need everyone to see everything the same. If we do what we already do, we get what we already got? Moderated traditional forums require an overhead and the privacy and security aspects of the Safe Network perhaps can allow more flexibility for what can be forums… or places people meet in the abstract.

The offshoot of this was half a thought I posted previously, that first element of url could be for topic, to make discovery simpler. On reflection I wonder that would need to be a sorted list, with :: as delimiter, otherwise the like of [Medical::Technology] would not overlap as the same as [Technology::Medical] which perhaps it should do.

Still having the option for the first element of url not ownable and available to anyone who wants to create a subordinate domain, would be very useful.

So, would need to it become possible, a fix of NRS registration to allow
safe://focus/icanregisterthisdomainname/whateveriwant.
where
safe://focus
is then still available to everyone else for whatever other subordinate domains they want.

My particular interest atm it thinking around the difference of a normal that is a bit of freedom on the normal internet and the Safe Network’s introducing privacy and security, requires certain capability to follow and part of that is asserting authority and/or allowing people to trust others by choice. Having a simple option such as safe://authority/assertingagent might make easier resolving what authority’s assert, in the absence of servers. :thinking:

5 Likes

Sounds like a variation of the pet name system.

Might be better to specify the naming system you are using, saving the requirement of having it in the URL. So maybe a set of naming systems to search. Thus if the name is not in the top level one then check the next level down. This could be a browser setting

There is no reason that the current NRS cannot be replicated by others to have their own version.

Thus have the default Safe NRS, then you can have a corporation/group/field NRS (eg medical, or Gov, or google, or country, or …) Then the user says in the browser settings they want in order “Engineering, Australia, Safe”) and the browser checks the “Engineering” NRS first then “Australia” and finally “Safe”

And to override the setting the user could have
Safe://focus:icanregisterthisdomainname/whatever

Using the “:” then means that its clear that its the NRS to be searched rather than a part of the resource locator for the site

No, this not about a pet name system… or continuity of the previous thread; and also that implies some one has chosen it… which is a force of will. This is about not choosing and allowing flexibility and option on location to everyone and not limiting what is possible. So, this is not the same as traditional urls, it’s suggestion an inversion against that first element.

Why search, when you can know where stuff is?..

Forums?.. look at safe://forum/*

but more powerful than that is what is centred on users
so, safe://[element]/AgentUUID becomes possible

Having browser do search, immediately throws a risk of delay… small clients will not have option on that… and users will not care for the wait for network responding to duplicate requests either. It also limits what is possible for finding basic detail.

As the topic title suggest and URL is defined those are intended to enable finding content… they are not necessarily about ownership and monopoly.

If the first element was available, then yes a subset of that would be option on pet naming whatever… but that’s a smaller interest from what’s possible with this flexibility.

Greed is not best - flexibility is best!
Normal urls are limiting for what is possible…

1 Like

This is a similar concept to the “public name reserve” I suggested a while back. I like the intrinsic structure and organization it offers safe as a “world computer”. Many others did not see value in it, which was/is unfortunate.

3 Likes

Could you link to your post?

I think this may have been the last time it was mentioned.

1 Like

I wasn’t one of them - thought it was an idea that deserved looking at more closely for various reasons

  • Avoid unseemly domain squatting rush at release - a potential negative slant on what should be a positive joyous occasion

  • Search becomes more intuitive

  • once the dust settles, the list of reserved words should be filtered by the Maidsafe Foundation for the real moneymakers and some (argue over this) sold off to bring in some funds for the Foundation - Perhaps accept only MAID in return for the rights (keys) to that namespace?

A dictionary is limiting, where freedom offers choice. Capturing all the variety in all languages for everyone, is a liability and extra work for no added value.

Lauding power over certain reserved words, is liable to petty politiks as bad as domain squatting.

Again greed is not good; flexibility is good.
Allowing the user to be agile, helps avoid exploits and politics…

1 Like

The public name reserve concept achieves the exact same thing and offers more flexibility. Instead of a proper word or specific name being owned by no one, it is owned by everyone, much like our common language. Automatically grabbing nearly every word in most all languages is trivial. Some of us already have the word lists and prototype scripts to do this.

Sorry for mentioning pet name, it just seemed a (major) variation.

I feel you will do better by separating the AgentUUID from “domain” by using a “:” so that the AgentUUID is not a strict part of the URL since it is just a naming system where the “domain” is found.

As I said the “AgentUUID” could be a part of the URL if one desired. But by allowing the browser to use default “AgentUUID” will save the user typing it in unnecessarily since not every URL will be from a clickable link.

By doing it this way you have the benefit of both without the loss of any benefit, like speed, and gain convenience

Did I imply that? Sorry if I did, it was more convenience and suggesting possible AgentUUID that will be there. Of course big corporations like Google and Apple will have their own AgentUUIDs.

That it did, but not completely.

Do not know how with AgentUUIDs would allow this. And there was no reason other NRS systems would not arise anyhow which would make this reservation less valuable.

That adds complexity… the URL is a resource locator… it finds what exists relative to the location.

You could use variable ?= if that worked but this is about landing visitors on content in the simplest fastest way for that. Perhaps certain content will be useful set as safe://application/username.

Still, AgentUUID was just an example and you could do something else but that’s just one of infinite options on this.

Of course, defaults and then alsorts of UI capability can accommodate user interest… but that’s missing the point.

The point of ownership and monopoly, is relating back to what exists now as traditional urls.

You can sit that minor interest on monopoly and domain name grabbing within
safe://www.[allIgotwasthisdomainname]

Saying it doesn’t make it true.

Surely, the opposite is true… you have a big dictionary but what’s the point of guessing a subset? Preferring a subset, adds complexity. Who can guess what is reserved as foreign languages unfamiliar?

The better option surely is we can simply understand every first element is flexibility.

Lots of activity is trivial but adds no value.

How so?.. obviously some sub domains might be attractive to owners but with so much flexibility added, most all of that selfish interest is removed… as there will be simple option on something similar where there are clashes of interest.
Certainly removing that selfish focus seems like a good idea.

1 Like

It’s clear to me now that you don’t understand how the previous NRS implementations worked. My suggestion is to spend some time searching and reading the forum to get a better understanding. There are easy ways to add structure/indexing of information and services via the current NRS without a centralized authority or added complexity.

but not clear to others.

You talked of publicly reserving words in dictionaries
not of some subtlety in the NRS.

“The only solution” is an assumption.

is not a complete catch all for everyone’s interest.

Seeking what exactly - explain yourself clearly; you were frustrated above that others did not get your suggestion before - don’t cop out expecting others to prove a negative.

I’d rather find what I’m seeking is landed simply and clearly!..

The profit motive from domain grabbing is a minority interest - better to focus what is greed motive against running nodes and rewarding as a positive feedback loop, than pandering to what is broke from the normal internet. Domain grabbing also risks the stink of “they are in it for a quick profit” that is too much of crypto alt coins… it’s not a selling point, it’s a distraction.

To be not completely it only takes another NRS system (using same method as the Safe NRS) to get any traction and that alternative NRS can have those domains available. Thus reducing the effect/worth of those reserve domains.

Lets say Google sets up an alternative NRS and claims better searching abilities then its possible that people will use their NRS. And this is possible with the current system

Is that not a bit of a stretch?.. would it bind applications fairly to one NRS - or add complexity for being sure which NRS was being used.

Surely the point of URL is that they are universal… or at least Uniform.

I’ve not seen suggestion of other prefixes than safe://
and surely that encourages common understanding of what the NRS is doing. Otherwise you risk confusion against which instance will be found with which application.

Perhaps there’s good reason for different NRS that is not about website content and hidden networks etc can make use of that. Focus atm is more about the common public web content, than what might be for niche bots and bespoke.