ā¦ And I donāt see a point in investing lifetime into a discussion that just exists to justify a decision that more or less has been made anywayā¦ (feeling reminded on the annoying encoding discussion that has consumes way too much of my lifetimeā¦ )
Wouldnāt it make way more sense to discuss this in the main forum anyway if you want to get the opinion of āmore or less regular peopleā and not only developersā¦?
No, actually I saying quite the opposite. Iām saying letās keep an open mind, letās think of the end user first and foremost, and letās find a way of testing so that we can have confidence in the decisions we are making.
I think weāve been pretty accommodating and open wouldnāt you? We are all sharing our opinions, and having them listened too, are we not?
Given that most of this chat stemmed from the fact that folk somehow were squeamish about PNS (which is pretty inconsequential in the scheme of things.) I donāt think you can say that. TBH if the PNS thing hadnāt be brought up, weād have probably just continued in calling them public names.
I was really responding to the statement that a 1. people didnāt care about the name (not true) 2. a democratic process wasnāt desired (also donāt think thats true) and 3. that simple, understandable, non-misleading names for new technology with a massively diverse user base can be created in just an hour of someones time.
Sorry that is not my opinion, name is important and why choosing an inappropriate name is very important not to do. Unless you want SAFE to just appear to be the current internet in peopleās minds by using the geek names - domains
I didnāt get this impression that people didnāt want to have a democratic process.
Which is why we should drop inappropriate names when shown to be so and consider more appropriate when suggested.
But we have the trend on the internet that the non-geeks have spoken they do want to use the term domain names and are using names like website name, website address, email address, and so on.
SAFE is simple for the user so there is no reason not use use simple names/terms/concepts so that the tech uneducated do not need to learn special definitions to understand how to access a safesite.
My suggestion is something like safename for how to refer to a name in the safe network. A name can be used for all sort of things, and so for a safesite it might be qualified and referred to as a safesite name or safenet address. For mail it could be safemail name. Address is not really legit for mail in SAFE since there is no address and its just the name entered into the mail app.
Not I am not against another way to refer to safe names, as long as its simple and fits with the way people think of referring to other people and sites now-a-days
Anyhow I think Iāll leave it there till good simple ways to refer to names is suggested. I have been pretty clear to my objections to complex references and the use of domains
Okayā¦ so I think we need to be able to move forward here. As this is all taking a hell of a lot of valuable time (thatās not to say itās not important, but just not where Iād nessecarily want to be spending that time right now while we are really in the thick of things!).
So how about a proposal to call the system Name Resolution System (accurate and agreeable, wouldnāt you say?), and then we can leave the door open to a useful user-centred descriptor to go before the name part as and when it becomes required by the UX design. And we can test this in context.
And perhaps in the mean time we can agree to keep it internally codenamed as Public Names?
There are a bunch of other elements to all this still up in the air at the moment, but once they have shaken out a bit, we can perhaps see it all with more clarity, and make a better choice.
NRS is the chosen by 55% of voters so based on that Iād agree
Personally i think the public and APP developers will drive this. Iād suggest that its not forced by any core developer or by others. In my opinion it will develop organically, so keeping it simple for now would be best. Public Names, Safe Names, Safenet Names, Safenetwork Names or just Name are all good for the time being.
Oh wow. Hadnāt looked in here for a while. Would have loved to see this level of engagement from everyone in a topic likeā¦ for exampleā¦ the entire SAFENetwork economy (just out of the blue) ā¦
What is it I hear in the back of my head? Bā¦ bike- something?
I read through the RFCā¦ Will anyone be able to register any number of public names, where the cost is just a tiny amount to write the relevant data? Does this mean that when the network launches there will be a gold rush of name registration, people rushing to register all the common and short names like google/news/weather etc? How will trading of names be facilitated?
p.s. sorry if this has already been asked/answered/discussed
Itās an important issue and indeed has been discussed with various ideas on what to do about it. Youāll find those discussions mainly on the community forum but there is no clear, agreed solution to squatting AFAIK.
Iāve just read the version with the latest pull requests.
A couple of questions:
This is probably discussed on the forum somewhere, but how does that work with an UTC timestamp being the key?:
As a consequence RDF data described here is a type of āversionedā data, with the key of an AOD being a UTC timestamp , and the value of an entry being a string representation of the RDF data.
Is it ok to have a āhttps://ā¦ā instead of a āsafe://ā¦ā-URL in this context? From the latest the latest RFC version:
So if you donāt append the version (?v=<version>') to a SAFE NRS URL in the SAFE Browser or the SAFE cli the most version recent is found/used automatically? Or is the version also required there (eventually)?:
And so in order to facilitate the Perpetual Web and canonical URLs, NRS containers will require that linked data MUST specify a version for the target data.
What is the first version: version 0 (?v=0) or 1 (?v=1). Or is version 0 the reference (like when you give no version number in the SAFE Browser), giving you the most recent version and version 1 the real first version.
ā If you look in the rfc you see 1 instance of ?v=0:
ā@idā: āsafe://thisxorurl?v=0ā,
And concerning version 1:
The RDF document will have a version relating to the version of the Resolvable Map data structure in use. (starting at v1 .)
Basically w/ āversionedā data, weāre currently putting a time stamp as a key (though the order of appends can be determined so this is just helpful for UI later most likely), and so you have: <now> : ` as each key: value.
ā¦ could you have http links? Hmmm, scheme wise I guess so (nothing blocking it atm), but would this be resolved depends on the app (and the browser would not currently). Should it be prohibited? Iām not sureā¦
Weāre operating under the idea that versions MUST be appended, so any change to underlying data, to be shown art a url MUST update the NRS map itself, thus making changes simpler to track on the domain.
Versions are 0 indexed. So yeh, that RDF v1 quote is outdated. (Ie v=0 gives the first version).
Apologies for formatting, on many iPad at web3 atm, quoting is a pain
Concerning the date: is it only informative (for humans), or is it also really necessary as (part of) a āprimary keyā (or to generate a unique hash/Xor address) to get the data, because is the version number not enough for that (and also for getting the correct order)?
Concerning the http links: Not that I think it should be possible. I just noticed it is mentioned in the RFC where I didnāt expect it: I would think you donāt want to access the clearnet to get the graph (@vocabā¦ to be more exact). If it is not prohibited, then the RFC doesnāt need to be updated to be ācorrectā, I guess?
The date is indeed only informative, and not guaranteed to be accurate (itās created client side). It could really be any value.
Re: HTTP, i think for @context (basically identifying the RDF schema), this is acceptable. There may be situations where you want to reference that youāre using a schema that is at home on the clearnet, so HTTP seems okay here. (Itās not like this URL is actually accessed in any way at the moment, itās just to know youāre using the same schema as someone else. Down the line, hopefully theseāll all be on SAFE. But I donāt think we need to block that atm.
FYI https://github.com/maidsafe/rfcs/pull/344 is the latest with a tweak sorting the v=1 reference to make that a bit clearer. This supersedes the previous (and I should be able to make any more tweaks directly there now).
FYI, Iāve submitted a pull-request to address some areas that were unclear/undefined. The idea is to make the RFC and the code match, and make these areas clearer for other implementers in the future.
Summary:
* introduce 'Top Names' nomenclature.
* introduce 'SAFE-URL` nomenclature.
* define 'Public Names' as SubNames + TopNames. finally consistent with definition as "equivalent" to `host` in a standard URL.
* Add examples for usage of `Public Name`, `Top Name`, `Sub Name`.
* change URL 'host' reference to DNS 'domain', which is a better match
* Re-write Path Resolution section, and include Version.
* Add section SAFE-URL Reserved Query String Parameters
* add 'Fragment Resolution' section
* Add a section on resolving recursive NRS-URLs