A domain
20 chars of 
What precisely is the domain referred by the domain name system? Itās not like I couldnāt register a domain ending with whatever I like bestā¦?
(yes - I just want to point out that the idea of domains doesnāt make too much sense in the context of safe - why should we introduce naming similarities if there is no connection on a technical level - sure if we call it DNS it would be obvious that the first part of a URL somehow resolves to the root of a websiteā¦ But above that it is only misleadingā¦ And this first part is just like anybody would expect it anywayā¦? So where precisely is the motivation to try and create a similarity/association instead of just a fun name? )
By far the most import point here, when it comes to naming the entity, is what general end users understand the term to mean. What happens at a technical level will be almost entirely irrelevant in that regard.
Nearly everyone using the SAFE Network will encounter this entity, anyone creating an account will have the make a decision as to whether to create one, and most will. This will be very early on in the on-boarding process too.
Giving it a āfunā name, or an overly ambiguous name, just adds so much unnecessary friction, and we will end up having to explain what the entity means in a context the already understand. For example, imagine this when creating an account:
āNow choose a funtag.ā
Whatās a funtag? Weāll need to explain:
āA funtag is like your own domain name on the network, you can use as an address for a site, or as your email addressā
Why create the need for extra explanation, whatās the point? The technical differences behind the scenes will be of close to zero relevance for almost all users, just as the technical details of the clearnet DNS is irrelevant to the majority of web users: itās how they practically function for the user which is relevant, and is what now defines the word ādomain nameā.
Itās really easy to test as well, just go and stop a few dozen people in the street and ask them what the phrase āDomain Nameā means to them. Youāll get answers like āitās the bit after the @ in an email addressā or āitās how people get to my websiteā or āitās what I type in the address barā. It has no connection whatsoever to the servers or IP address ranges behind it all for the vast majority.
Domain Name has become a term that describes quite accurately what we are enabling for end users and, for them, will function in the way they expect. So I propose we use it.
3 Likes
Uhum - it will mean nothing to 90% of people - and most of the rest will tell you itās a name for an ip address imho
The name chosen here is for a highly technical target audience if if coming with ādomain nameā in it and those will likely be a bit confused because it is misleading in the context of safe - and for the others just calling it āaliasā or āreferenceā or simply ānameā might be easier to understand/more intuitive 
1 Like
You think that most people donāt have a definition for the word ādomain nameā?
This is really easily tested BTW. Iāve already started that.
1 Like
Absolutely - I donāt have the slightest doubt most people have never heard of it (and just seen it as router setting but didnāt notice)
1 Like
The name for the system might be for a technical audience. But the name for the entity needs to be understandable by all users of the network, as theyāll nearly all be confronted by it, and need to make a decision based on their understanding of it.
1 Like
I think we might be talking about two different things here.
I agree most with view the acronym DNS like some strange router setting, that they donāt know or need to get involved in.
But what Iām discussing is not that; itās the entity itself. What to call the name bit. What do people all the thing in the address bar, or after the @ in an email address.
Itās a domain name to most, and this isnāt very technical, itās the common understanding.
And if itās not a domain name for most people? What is it? (itās not hard to find out)
2/2 (electrical engineers => [I innocently asked and didnāt imply anything] names for ip addresses) on this side of the world so far
Edit:
The thing after the @ is your email provider - what else could it be? 
Ps: possible that itās just Germany that is living on the other side of the moon but I can guarantee you nobody (I know) would think of calling it the domain name here and calling it this for sure results in a needed explanation
But flip things round the other way, and (taking some new people) ask them what they think your fun-made-up-name is, or confront them with it in a user test, and theyāll need extra explanation. And youāll probably end up having to resort to āitās like a domain nameā.
Iād just call it a nick name or alias
Nobody would ask questions then - everybody would know what it means
(and the system would be naming system or alias system)
Ps: sure with a fun name youāre in the same situation (kind of) but at least Nobody would wrongly assume heād know precisely what it is 
I donāt think they will. If asked in a GUI form to pick a nick name theyāll probably think, "what, a nick name for me? For my profile? Like āJimmyā?
Itās gonna need context, and more explanation, and to translate well etc. Whereas Iād wager thereād be far less confusion with Domain Name, as itās so extensively used.
But again, can be tested.
If thatās the case in all English speaking areas then thatās probably a smart move - but when i mention our company domain server in a conversation with close to anybody here in Germany I will just end up with someone staring at me and telling me that I cannot expect others to be IT professionalsā¦ So at least with people here this will just generate confusion and the feeling of not being the target audience for this technology
Possible that using Domain Server might be the alienating bit.
But back to what we call the entity. If you have any suggestions (which Iām totally open to hearing), they can be tested too.
Iām not saying Domain Name is perfect. There wonāt be the perfect solution, but just one that is the most understandable/recognisable for the most people, given the context.
I mentioned the domain server because thatās the āmost common caseā you could use domain here and have people nod because they know what you talk about (and not mean just the name to ip resolution)
Ps:
The problem is that I donāt know a perfect solution eitherā¦ But if you want to target the average people on the street youād probably be more successful here with something more figurative
- network identity
- network identification name
- network name
- safenet name
- alias
- global reference
- personal link
- SAFE ID (with little description what it comes with - because itās needed anyway - even if people know about domain names they will check back to make sure they donāt interpret it wrong )
I think we can rule out any with reference to Identity or SAFE ID, as they will be the preserve of identifying individual people and profiles etc via WebID/SafeID. Thatād be a whole mess of confusion.
1 Like
Unless the simplest will be for us to have one entity, rather than one for domain and another for WebID. We should consider that - rolling all these functions into identity might be the cleanest and most easily understood UX.
Going back, I donāt think domain is well known so Iām interested to see how tests on that pan out.
My guess is that people donāt understand domain, but instead would get āwebsite nameā or āweb addressā and āemail addressā, but go blank with anything including ādomainā.
I donāt think these map well to the entity on SAFE, so while I agree it would be best to do that, Iām not convinced that domain will achieve this.
Which leads me back to wondering about using āSAFE WebIDā as a catch all, and then to hang services/functions off this (ie your SAFE WebID is a friendly name you can use to publish websites, for email, to share files, and as an identity for social networks, chat applications, and for sharing information about yourself on those services in the form of a user profile).
I understand that technically a WebID is made up of the more granular ādomainā entity (plus subNames) - but is it useful to expose that in UI?
I think the domain (the entity weāre discussing) will be the layer above these other functions/things, and be the starting point for how these other things are addressed.
In my mind, from a UX point of view, Itās useful to be able to separate out the use of these functions, and in particular SafeID/WebID as a way to addressāor identifyāan individual person or entity. As opposed to just addressing any class of data.
Itās likely that weāll have a form of address thatāll make that useful and obvious. I.e. @<subdomain>.<domain> is where Iād find a SafeID profile, and itād also be the address I could message/email an individual, or mention them in a forum, or send them some safecoins.
I know I can get to your website by typing in happy.being in the address bar; and I could also message you with @happy.being; or see your contact information, link through to all your latest commits on your profile, by dropping in @happy.being in the browser address bar.
So the SafeID address is built from a domain, but does a different job from a website address, and has more context than just a flat domain.
I think itās handy to be able to call them different things in this case, but still know they are related.
I think you are now arguing for the technical reality over the simplest UX. 
Iām suggesting that by using the whole WebID or something like that as the starting entity (instead of domain which is a technical building block) explaining, learning and understanding may be easier.
Example using SAFE Name as the entity:
- your SAFE Name is a friendly name you can use to publish websites, for email, to share files, and as an identity for social networks, chat applications, and for sharing information about yourself on those services in the form of a user profile
But rather than create this in two steps (domain, sub domain), we start with the general case which will be like WebID in almost all respects, so creating a SAFE Name will always result in me.<something>, but we donāt refer to the separate parts. This is a SAFE Name, and it implies a SAFE WebID with user profile (eg safe://me.<something>/card#me).
Once you have this, it provides default forms for email <anything>@me.<something> or @me.<something>.
While for websites you will have an address ready at safe://www.<something> perhaps already populated with a simple homepage (optional checkbox during creation?).
Can you outline the equivalent UX workflow you have in mind for 'domainā? Maybe Iām not seeing how you plan to lead a user through that process.
If we go in the other direction - create a domain, add a website, I think it is letting the technical detail drive the UX. By calling it a name or an identity rather than a domain, I think it is clearer that this leads onto things like email, website and other services. I think people are more likely to get concepts āyour name on SAFEā than āa domain for SAFEā when making these very early steps.
1 Like
Oh, I have a habit of arguing round in circles until things become clearā¦ if you go round long enough eventually contradictions wear off
I do my best to try and put my self in the position of the user, but absorb the technical landscape enough to be able to hopefully at least get a feel for the limits. Threads like this are enormously helpful.
The UX flow in detail for this we havenāt quite come to yet (from an account creation or publishing POV anyway) weāre working through some read-only scenarios at the moment which will help inform all this later as well.
But from a more broad perspective we try to think in terms of user being a single unique human, who may have multiple identities (a way of presenting a form of themselves to others): some identifying their unique self directly, some pseudonymous. And of course not forgetting an internal life that isnāt associated externally with any identity.
They may also have a multitude of files, some public, some privately shared, that they may chose to associate with one of those identities, or not be associated with an identity at all.
So there needs to be the flexibility for an individual to maintain and publish content in and accessible and human readable way, without the need to create an identity, but create and share or publish with an identity if they choose to.
A building block of this is the thing we are referring to as a domain or name etc.
I might have an identity that publishes to many different domains; or I might have many domains serving up information that isnāt associated with any individual or organisation at all.
I think the most useful initial starting point for many people will be to create a human readable address capable of receiving/send safecoins; or private messages. A pretty good starting point for most Iād have thought. But I donāt think we should be assuming that is the case for everyone, nor that āidentityā is the best place to startā¦ it probably should be opt in to identity (be that private or public) rather than opt out.
(Then thereās also subtleties like one-way only communication, and how people will address that)
So Iām still talking myself into the core of this being the name/domain; not the identity.
I may chose to create an account, and have a bunch of human accessible addresses publishing information in the form of safe://:
safe://sports
safe://politics
safe://arts
Maybe I have a real identity, which publishes to these (in the form of @<anything>, and itās @realme. I have a SafeID profile set up at safe://@realme that makes that link explicit. Iām the owner of those names/domains, and the comments and posts blogs are published as @realme.
Other users can get in touch via @realme or messages will get also through on a specific context via @politics
Then I have another which is @fakeme. I allow @fakeme to gust publish on safe://sports sometimes, just for fun.
But then I have another site safe://fishinganonymous which isnāt associated with any of my identities, nor with any other user, entity or persona. It has no published SafeID profile, It just publishes stuff about fishing, but readers still send in anonymous tips by addressing @fishinganonymous.
A bit of a long reply, sorry!
Nothing in this is precluded by the approach you set out, but how we create the language, or workflow around these terms, starts to build a mental model for users that effects and forms UX, so needs careful thought and attention, so great that itās getting it here.
1 Like