Discussion on the use of Public_IDs in Apps

As we see new Apps pop up for SAFE, I think it’s time to talk the “Public ID” again. There’s an older discussion here that talked about the Public ID in a broader sense.

Should all Apps default to use the Public ID?
What if you start a chat_app or an email_app? What if you want to upload a website? Start a web-RTC video_chat… Should all these apps use your Public ID (aka: handle, public name)? My answer to that question would be yes. let me give the explanation here:

  • It’s very user-friendly to register 1 name and use it all over the network in different apps. Imagine your mom or dad registering 1 name and have to choose a new name for each app again when they use it. That wouldn’t make sense. I’ve seen this issue on another cryptoproject where there are around 6 or 7 apps in the make for everybody to register a public name. I think that’s a mess.
  • Another reason to use just 1 Public ID by default is to (partly) limit the possibility of ID theft. Assume I use polpolrene as my Public ID, and I start a chat_app and see someone else uses my name for the chat, even though it’s my name on the rest of the network… this could be a serious issue, it would assume one has to always hurry up when a new app is launched to register a name.
  • Another reason is that it’s more userfriendly than the current internet where the reason as mentioned above makes you always have to look out to see nobody steals your username on some social network.
  • By always defaulting to the Public ID the idea is supported to only have to pay once to secure your name.
  • It also makes people more recognizable if 1 Public ID is attached to all apps and forums etc. If I speak to @someone I know it’s always the same person, no matter if it’s on some app or in some chat.

So, overall I think all apps should default to the MAID Public ID. I think this was the idea from the beginning on, but not sure about that. I’m also curious if this will be supported on Alpha 2.

Of course everyone is free to register another Public ID and to use several. Or to use apps that create in_app ID’s.

Just some thoughts… Let me know what you think.


I think it’s a sensible default, but apps should also allow us to choose other available IDs (we can expect more than one or account, though it is undecided at this point AFAIK).

I don’t think there’s an issue with people impersonating you with a duplicate ID. You own your public ID, so different apps can’t reallocate it to someone else. They could allow it to be displayed differently, but that is a different problem and I would recommend people avoid apps that allow this for the reason you mention.


We’ve had an email_app some months ago and you had to choose your username. Now these are POCs so I understand that not everything is made with all these details put in (already cool we’ve had email in the first place), but we both were able to choose whatever name possible. So I could’ve chosen your name and you mine, depending on who was first ;-). That’s the point of this topic, to see if there’s an idea about this, a focus for Alpha 2 and upcoming official apps. And would like to know how external app-builders think of this subject.


That’s exactly I am working on right now. I’m learning Rust, so I could fork the DNS system(that’s why I asked in dev thread, what happened to DNS folder), then switch to “NO DNS / Pet name system.” I do not like the maidsafe version DNS model at all. This DNS will automatically create random generated ID. Then it provide an id config file, which would contain omniname, just like steam usernames. interchangeability. Each config will hold specific information on which user could access to which files, and such.

rootname = 294792389797
omniname = grizmoblust

user1 = 078977823423409

The first thing when you click on his profile, is to look at his config. Some of his profile will open up for certain people with black/white list.

I think this is much better approach than what we have right now.

Not only that, when you access to his profile, it is like looking at his file system. One could look through his files, and folders (with permission, obviously). It then becomes a personalized NFS system. This will push towards less junk websites, and push towards social content system.

Each random generated ID includes email ID.

Edited: This is what I wrote on my RFC few weeks back which is obviously not done. A lot of errors, and such but let me know…

What is wrong with safenet Official DNS system?

Official dns system allows apps to control the users contents.
Whereas, no dns proposal will change the way app functions, that is users are control of the apps and it’s contents.

This also could lead to hypervision system where you can run OS inside of safenet. Your personal hypervisor system.


You may be willing to share your hypervisor to others. Or perhaps have a join accounts. Two constent rootname signed into one rootname. Thus creating an joint, organization, business, etc. Each changes requires approval from each joint account that is signed, matching [keys] list.

The key list is your “contracts” dealing system. Once pubkey is signed, next script would pop up, to create new contract with functionalities, change, or fork.

The best part about this is that you can send him a message wtih that ID. You don’t have to generate another ID. Simply send to 787986124987. This will generate a new SD system, a put that is spend by the user. Then it would be saved into logs folder.


To control the users on your own rootname system. You need something exactly like sudo functionality. Perhaps, make it more simpiler format. It would take from key folder, and put into function algorithm to decide how users save and maniplate the files.

List of public keys

publickey1 -> only can modify 787986124987/docs/

Now organization can actually give users place to save their files only inside of that organization. Meaning that organizations are WILLING to pay storage, so that users can save stuff which cannot be shared outside of the organization. You are logged into their rootname/users/name1… from your pubkey.

publickey1 -> only can modify 787986124987/users/name1/


To return to the original point of web of trust. When we enter a rootname, it doesn’t do anything but show his ID. In that vcard would have stamps of approval from organizations, and individuals. Again, it doesn’t have too. It’s part of building web of trust with competiting organizations stating that he is either this or that. We need more honest people and to do that is to create micro dns competing field. Each micro dns contains reviews of each rootname. When you random click a link in the network, the micro dns would give an expression; safe, netural, dangerous, or unknown.

MicroDNS is a public SD controlled by a man, or organization. The first column is list of the official rootname directory. Second column is how people like to be named.

Keys are stored in .toml format. We need to extract the pubkey, and put into function that would make a determination to pass or not.

Now I would build a script in rocket-rust
let key in keylist { //this is accessing to 787986124987/keys/
if pkey == accept
then show this…
else = break; // blocks access

How you want to name him is your “nickname” convention. This is saved in your private folder.



How to add reviews is quite simple.

Each mutable data would contain users commenting about him, and how trusted he is. It is infact indeed public. Saved under 787986124987/reviews. But of course, that requires rootname to allow people add comment in MD reviews.

What if user ID doesn’t accept reviews? That’s where you fall back to micro dns organization of choice, and write a review about this particular rootname.

But what if you want to have multiple “characters” without ties to rootname. Like Master Cheif, don’t you want to review him, instead of the actor itself? But what if there are 10 other master chiefs? See the problem here? How can you give actor an review about that paritcular character?


Okay, you saved masterchief.obj, and when you play garrys mod, disguise as masterchief, people are awed by your 3d artwork, and how well it act… They decide to review it.

users would have to be allow to write in that particular folder. Keys are good for signatures. But it isn’t needed since it’ll be in public. However, you want to prevent them from accessing users.

chmod 0700 787986124987/users/mastercheif/reviews


But this would be annoying to get to DNS and review system. So to build a better system is to UI that does not require to use URL! Crazy but it’s doable. The function is to recursive through the folders, and take the names, and then prop to new screen. However, what about multiple items reviews under one business?


As you see, it is very versible. It is just matter of saving where and why. And to do that, you need give users more control on where it should be saved.

If you design a game, and want to share to the world, it would work exactly in a way app would be installed on the machine.


Now we got a highly complex system that gives users control of their own security files.

What about git, and source files?

That is a highly complex system to get into. Say, if you want build a more hackable system for users, such as zeronet, dat, and Beaker Browser, then how can we make it better? Well forkable system is quite easy with git. But the problem is spending money, to recieve all files, and change one slight file. Well one way is to fork that file, and make the app point to that file instead of personal user file. Oh boy getting too complex here.



Inside in that file,
doessomething() = linkto.(787986124000/apps/halo/git/cra77s))

Now you able to run that user app, with extention of your file. Everthing goes accordingly to your plan.

But why should we save our apps on our own system, where we should put into game.library/halo? Or

Well you can do that too. But the point is here is about giving users more options on the table to control the data flow. If you build it yourself, then you can place it in your own folder, and share to the world. TThat means you gain karma, and showed the world that you are skillful to build a game. Instead to realize that organization doesn’t invent things, individuals do! Invididual matters. But organization is jut group of people working together.

Even more sane system, to keep it modular, each rootname could be an app itself, nothing else.


As you can see, we don’t actually NEED safe: //name.name when one could be enough, competing micro dns system will be build on top of that. Game Indexing DNS. App Indexing DNS. Think of the possibilies here with this approach. And of course, you’ll get malware but that’s wild west. Wild west is the best, because it competes. With safe, wild west is much more SAFE!


Bound to the root concept of Privacy surely is choice.

Errors follow from assumptions… and that everyone “should default”, is an assumption of what is best for everyone. If there is no need for it, then why impose such a limitation?

Having a default profile, is of course a nice idea but surely it would be rare that anyone would have only one. I’m tempted to allude to Google circles, as a concepts of how individuals - most individuals, have more than one profile of interacting with the world… at least you might expect public; acquaintance; friends; private arenas… and at times with a need to not overlap those. Google Groups or whatever it was called sucked; so, we need something better than just that.

Of course everyone is free to register another Public ID and to use several.

but such an option would need to allow two apps to run alongside one another using different names… forcing a users to log out and log back in, is as not practical as expecting them to not want multiple personas!

One person = many personas. How those relate to PublicIDs I don’t know… if logged in to a PublicID, then one PublicID should :open_mouth: … perhaps should :slight_smile: acknowledge many personas… but would that risk a violation of privacy, for example in the case that the PublicID was confirmed and then necessarily those personas bound to it?

For all the technical quality that may ensure that PublicID is not a liability, I wonder most people with any reason would be cautious, at least initially trusted what is unfamiliar and unconfirmed by their own peer group. We can’t change human nature… and we should not expect to control it… down that path lies conservative errors.

So, whatever there is needs to be flexible to satisfy the interests of Everyone.

and I wonder if that points to a solution … if it became possible to login to multiple PublicIDs, that would help resolve concern about spoofing PIDs and allow flexibility for Apps to acknowledge a users preferred PublicID only being blind to the others they have.

or perhaps that was what you meant by suggesting:

Of course everyone is free to register another Public ID and to use several. Or to use apps that create in_app ID’s.

but my reading of that was relative to what we have now, where you would logout of one and into another PublicID.

If any App can see the PublicID, then there is no privacy relative to what other Apps might interact with that same PublicID… simple comparison of two datasets would break the user’s privacy.


I would think that as long as this remains true, then we keep control of our online representation.

I would say that trading ease of use for privacy should be a possibility for those who want it, not something you are bound to by the system.

Google, Facebook and their little friends spend billions in trying to make us have a single online ID, and to have it bijecting with our physical person.

One of my biggest hopes in Safe, if not the primary one, is to make the opposite not only possible, but unbreachable.

So my thought on this is precisely that : apps should be able to run under a single ID , but one should be able to have as many IDs a they want.


Which is an important point… SAFE needs to take responsibility for Privacy, beyond just expecting that users will look after themselves. Data is powerful, beyond what most people understand… it’s trivial to leverage data to something useful outside of people’s awareness.


Just one point I think is wrong, and please correct me if I am wrong.

On SAFE once you register a ID with the network you “own” it. Someone else cannot come along and use it elsewhere since they don’t have the private keys and the network won’t allow an APP to re-register it.

Personally I think it will be good for people to have a number of public IDs depending on their circumstances and uses for the public APPs. For instance on a health & wellbeing set of forums I may wish to have one ID, but in the tech forums I may have another. I don’t want to link the two because people might judge me in the tech forum based on my health.

Mom Dad, well I resemble that for the last 30 years and those people may want just 1 or maybe a few. The APP would simply ask them which of their public IDs they want to use for that APP. So for instance they may have one ID for using where they don’t care if their kids know its them commenting, and another for mum’s&dad’s friends at the casino. You know the parents might prefer to keep those two “worlds” separate so the kids don’t think their parents are gambling away the inheritance. Don’t worry the only casino I have been in is the one I did contract work for.


I was planning to build a personas app as my first project on MaidSafe once they launch a new Alpha with the Authenticator and Mutable data pieces done.

For users, they can create multiple personas, each with a customizable set of metadata/claims they want public for that alias, and get a public webpage with that information. Sort of a cross between Mozilla Personas, Gravatar, About.me - a modern web whitepages.

It might be interesting to integrate an RSS feed into the profile so users can aggregate links to public content they create in other apps - a sort of Feedburner.

For apps that want to integrate, they simply ask for the alias when the user signs up with the app and then read the public profile data.

I certainly don’t have all the details fleshed out and would love to collaborate with other devs who would be interested in a project like this.


I want to have many public accounts because I don’t want my work stuff mixed with my whistleblower stuff mixed with my personal stuff mixed with my truly private stuff.

I don’t want a default account. Picking an account for an app is a high-impact decision, so I want users (including myself) always reminded that an app has to go through an account, and it matters which one it is. I want to be able to create an throwaway anon account for an app with a click, too.

I want to be able to see at a glance which one I’m using. When I do something in the real world, I act from a specific role and, the well adjusted adult I am, I don’t usually mix them up because of the obvious clues: I’m at my workplace, I’m in my bedroom, I’m in a coffee shop. These clues are, however, completely missing from the digital world. So, we need to find a way to provide them :smirk_cat:

We could have “themes” stored alongside each of our personas and apps, that follow GUI guidelines, would display them to give us visual (and maybe auditory) clues about which persona we’re acting as. This would significantly lower the chances of drunk posting questionable party pictures to my work account (not that such thing would ever happen.)

I don’t want identification be based on names. (EDIT) CatVideos vs catvideos vs cat-videos vs cat_videos: will you remember, which one is me? Protection against ID theft can’t depend on my ability to recognize names; it needs to be assisted by technology. If you see that “catvideos” is one of your contacts, or is trusted by some of your contacts or, depending on who we’re talking about, the president of your organization, country, etc then you can trust it’s the person it seems. But we’ll need the same kind of distributed trust thing for apps, websites, etc as well.

I want my accounts separate. However, I can imagine a scheme where my accounts are organized as a tree, where I can log on with my master account to access them all, but I can log on with just a leaf account if I want to make sure stuff can’t get mixed up. If it’s a tree, then of course I can have a master master account that, in turn, has a master work account and a master personal account under it, and so on.

I want my accounts isolated from each other. I want to be able to switch between my IDs at ease, but I also want assurance that a rogue app can’t copy/paste stuff between those of my IDs that it’s connected to from the same device, but e.g. phones don’t support isolated installs of the same app at the moment. Honestly, I have no idea how to go about this one without selling snake oil.


Stepping out of specifics for a moment, I think we may also need to differentiate what we in this community personally want and what we want to create that will be the “best” general default UX.

Every (sensible) suggestion should be considered, like @Tim87’s here, but the conventions we want to establish for apps, with the broader population in mind, will likely be different than what this community would want for ourselves.

More general defaults will I think be a balance of what we think serves the average, or better median case, as well as we can imagine and design for it.

This will I think need to try and balance usability and likely user priories, with a sensible degree of default OpSec. Ease of adoption will be vital in giving the network traction, and ensuring that as many people as possible get to hear of it, try it, like it, use it, tell others about it, and so benefit from the security and privacy it offers while bringing more and more perks to the SAFE party :tada:

So I suggest that as well as designing from our perspective, we need a way to reduce the negative impacts our particular preferences might have for adoption or usability in the general population, or in terms of simply what ordinary folk expect and desire.

Maybe we can design from both perspectives, perhaps separately first, and then bring them together to deliver maximum benefit to all. While also ensuring that those wanting higher levels of privacy and security, or simply more specialised types of use case, can still do everything they want, and will have ways to set this up so for them these are defaults where that’s wanted. Maybe different SAFE “distros” (not my idea :slight_smile:) “desktops” or similar?

Phew! Hope that makes sense. It’s a lot of words.


I suggest this topic continues as is, and be used to come up with sensible menu of user requirements, and that we split off discussions for any specific types or groups of user. We could then bring these wish lists together again.

So, for example the users to consider could include types such as:

  • the median user who if they adopt en mass, will be sufficiently numerous as to place SAFE alongside Facebook in its popularity (so people who are not technical, and who’s conscious priories lie more in getting things done than security and privacy, but who will nevertheless benefit enormously from SAFE)
  • early adopters, geeks, and high risk individuals (ie people who recognise the threats, value SAFE, and have the motivation and ability to squeeze the level of benefits from SN that they need)

We may want to consider other groups as it’s a big leap between these two, but that’ll do for now. I hope I’ve explained the idea.


Agree with that - it’s vital to have the average user in mind and focus heavily on UX. That’s the way everything is going. I guess the real question is what must be set in stone at this stage and what can be altered after the fact. @tim87’s concept of a master master account from which different permissions can be controlled would seem to be a good compromise between security and flexibility, although I do wonder what people will do when they lose their credentials for that account or have them compromised in some way, which will inevitably happen.


I’ll stick to the idea that as long as I can create and own as many ID’s as I want, and destroy them at will, I’ll be happy. I personnally don’t care much if I need to do my own homework to handle which ID I am using at the moment, logout, then login with another if I need to change my online “persona”. ( I suppose I am in the “have the motivation” group :slight_smile:
Now having themes with colors or backgrounds specific to each ID would be a real good thing, as it would help to prevent mixing things and post private things on a public channel for instance.
This being said, I agree, too, that for the average joe, my stepmother, and mass adoption, a single ID with just one identification process, that then allows you to run various applications without further annoyance, is really important. This was the idea behind the launcher I think.

I do also agree on the fact that an app should never be able to use an already taken ID . I think it is already the case, as it would be denied account creation if the ID already exists.
But how could we prevent someone to write a chat or whatever app that allows you to create alternate names and use these as nicks instead of Safe Ids ( which is cool ! btw , eg for games ) ? I am not sure. I like the irc approach : if you don’ t register your nick, anyone can use it. You can check which IP is using it, though, which can give some clues. Then if you register and enforce it, no one can use it but you.

Maybe Safe apps could implement something similar : if I don’t register my HypeSafeChat nick, anyone can use it, but right click or whatever button allows others to see the original Safe ID that is currently behind the nick. If I register the nick , then HypeSafeChat would deny any ID but my own to act under this nick.

I suppose it would be the app author’s choice to treat nicks and IDs responsably, or to not give a damn about it.


I like the way Chrome manages multiple users - simply select the user you want, and a new window pops open, and all things google will open under that account.

Would be great if it could be this simple within Safe Browser… though I guess it’d be simpler, as only 1 login, and not constrained to google.


I think the best way to go about it is not from a design but from a requirements point of view. Let’s throw in everything we consider important, figure out the best way to model it, and then how to present that model in a way that is easy to understand and use. Then let’s make it pretty.

The point here though is that the order is important: SAFE is about solving security and privacy problems, so it would be a mistake to start from an “ease of use” direction, no matter how important it is to get there in the end.

Making a secure design easy to use is easier than trying to retrofit security into an easy to use system.

It’s all open source, and I’m sure groups with different focus will come up with different approaches towards e.g. implementing the GUI for the Authenticator.


Much of SAFE is not about the technical solution, but about what we’ll do with it. If we come up with good design conventions and easy to use developer tools that support them, we will end up with a thriving ecosystem, similar to that of e.g. IOS apps.

So, while there is no technical solution to enforce e.g. public SAFE IDs as user names, if enough app uses them, people will be naturally distrustful towards apps that break that convention.


+1 @Tim87 this is important so well worth us putting effort into it.

As a community I think everyone can contribute to this because we are all users, and all have an understanding of the goals and functions of SAFE. And almost all of us have already played with the UI and will have begun to see areas we like and dislike.


By the way, my idea about a hierarchical tree of IDs, for example, is completely doable with just forking the Authenticator (that is, if it’s not going to be part of the default implementation.) Different distros for different people, right? How else could we have religious wars in the future about which one is the best? :joy_cat:

No, but seriously. If this thing gets adopted, we’re talking about a ridiculously huge scope, on the scale of IOS, OS X, Windows, Linux, Android, many of which are also fragmented by toolkits and desktops (think Gnome v.s. KDE.) As varied as the programs built around them will be SAFE apps as well, but we’ll need to make sure we have enough common conventions to allow all of those to cooperate; we don’t want another “oh no, this app only runs on Windows” situation.


I agree, or even an app can do this I think, a BIP thingy based app that generates a tree of accounts as needed, and handles logins below the root for you. Maybe? :slight_smile:



So we can find winners in each area

1 Like