I think we still have plenty of time to figure out these before anything gets set in stone, but I also believe the way SAFE is built makes things rather flexible.
From among my ideas, the master account idea is backwards compatible with just having independent accounts, and themes could be implemented as a folder with some JSON+images to which all installed apps would automatically receive read-only access: it’s all just conventions.
However, that’s exactly the point: it’s harder to change something when people are already used to it, so we could might as well start out with something good enough that it won’t need much changing.
Well, yes. However, as logging in to a master account would introduce ambiguity (which child persona should the app use?) why not decide master accounts are just “private containers,” and apps logged on to them should not use a public profile (i.e. it’s no longer a question which child persona we should use.)
Master accounts would still be useful for organizing personal stuff (e.g. copying between accounts) but they wouldn’t be very useful for social apps, which means people would not be logged on with them on their stupid phones unnecessarily.
IMHO, I see a very small contingent of users that will want to have multiple SAFE master accounts, and will be satisfied with logging in and out of those accounts in order to keep the data and activity between those accounts completely separate.
I believe the majority of users will be more comfortable with having a single SAFE account that they log into across their devices. This will allow them to receive notifications, move data between apps, etc, which provides a level of ux that most will require.
So, if the MaidSafe team has not designed the concept of personas into the account/authenticator system, it seems a little late in the game to expect this to become something that is baked into the SAFE network architecture?
So, it seems to me as someone who is just joining this conversation, that the issue, (demonstrated by the sample applications), is that every application asks for its own alias and has its own profile (which is mostly what happens on the web now), and is kind of a mess, and adds complexity for both users and developers.
If, as a community, we want to encourage application developers to adopt a universal persona system instead of building a custom system into every app, sort of like the OpenID Initiative was trying to achieve, then fairly quickly it needs to coalesce around a shared project, get something built, and publish open data structures and integration guidance?
Boils down to whether one PublicID risks breach of privacy between applications.
It maybe the case that there’s no issue; equally there might be no issue have later some authenticator that can acknowledge multiple PublicIDs logged in with one as a default and others for certain applications.
The priority is naturally to get something up that works well at a network level; if that can be done in a way that does not limit what is possible in future for adding flexibility and empowering the user, that route should be preferred.
Do you not think there may be a significant number of people who will use Safe for work and home, and would like to keep accounts separate (like many do with google accounts etc)? I’d want my work and personal safe accounts logged in on my PCs and phone, but in separate browser windows / apps etc.
Not handling this issue well would be a frustration for many users, but I don’t think it’s a matter that will be an issue for the core network architecture, but more an issue for the browser / authenticator software, which shouldn’t be disruptive in any way to the network design its self.
And that is my problem, actually. With SAFE, a lot of how we think about the network changes, which gives us a great opportunity to alter how people relate to their online presence.
As I argued in an earlier post, we don’t treat “real” life as a monolithic whole, either: we partition it to different roles, and we present ourselves differently according to the situation we’re in (e.g. studying at the library in uni v.s. fun at the pool with friends v.s. being the company CEO at the office v.s. being the mom at home.) Qubes OS, for example, went in this direction: its “domains” group related tasks and isolates them from other domains.
We don’t have such obvious situational clues in the digital world, and people are largely unaware about the dangers of mixing their public and private and professional lives within the same account (until they don’t get a job because of a long-forgotten party picture, or get fired for a not so long-forgotten one.)
By the way, Google is already doing the multiple accounts thing spectacularly well: whenever I authorize a site, it gives me a list of the accounts so I can pick the one I would want to use.
A lot of the friction with regard to handling multiple accounts the way you are suggesting right now is mitigated by the fact that applications and server processes are able to do things for you outside of a currently logged in authenticated context. Applications running in the background, or as server processes can use stored authentication tokens or elevated permissions (because they control your data) to do things for you when you are not logged in. The huge benefit, but also a huge constraint on SAFE network applications as it appears to me, is they only have access to your data when operating under your current authenticated network context?
I definitely agree with you on the need for personas. Most identity systems today are designed to provide hierarchal identity contexts that involve a master account and sub-accounts that can inherit or override from the master context. MaidSafe doesn’t seem to be designed this way, and given the application architectural constraints of a p2p client-only solution, multiple accounts seems like it will offer a very poor user experience to users.
Let’s take your example with regard to a simple phone call. I probably have different phone numbers and email addresses for work and home. But I don’t carry two phones, and I don’t run two copies of my email app. I forward both my phone numbers to my cellphone which can respond to calls for both numbers at any time, and I have my single email program log into and send/receive from both my home and work email accounts simultaneously (with stored credentials).
I don’t see this being possible with MaidSafe where you will be limited to a single authenticated context at any one time. Right now, if you are logged in as CEO at the office, you won’t be getting any emails from your family, and you won’t even be getting notified they need to contact you?
Qubes OS is a great example, but Qubes also allows you to have multiple virtual contexts operating at the same time, and easily move between them because you have the overall context of your whole device desktop. This seems to mimic the idea of a master account with sub-accounts more accurately than separate accounts where you would have to logout of one account in order to login to another.
It seems to me that the perspectives being debated in this thread need to be tempered by an understanding of the very real constraints that distributed applications running on the SAFE network face when compared with how the Internet works (and doesn’t work) today. Most of the arguments with regard to the lack of privacy and security, and control over your information is exactly what enables much of the user experience convenience that we enjoy.
The biggest mistake made in the evolution of the Internet and the web was the lack of a robust identity system (that supports personas) was not baked into the system, and everything we have slapped on after the fact has been mostly terrible forcing a compromise between convenience/functionality and privacy/security.
I am very much concerned that MaidSafe does not seem to have answered this challenge yet. Am I missing something?
Oh - and sure, Google is handling the user interface of switching between accounts pretty well, but remember that all their applications have access to all your data anytime they want too
This would indeed be a real constraint, but I don’t think you’re right: there’s no technical reason why an app couldn’t use more than one access tokens at the same time.
The downside is that then we depend on the app to honor the boundary between those accounts, but I’m not sure there’s a way around that. Also, this is only a problem for something we expect to be really secure and private; we use apps (e.g. email programs) like this without wasting a thought on this risk.
We could of course run multiple copies of the same app, sandboxed by the OS, so that they can’t access each other’s authentication tokens; it is possible on desktop, not so much on mobile, at least currently.
As for background apps, there’s no reason why we couldn’t have them. Your mail app on your phone is connected to (or is polling) the server (or servers!) in the background, and SAFE apps could do the same, for multiple accounts, if necessary.
This is correct, but it’s a decision, not a constraint. Anybody could run a service that accepts access tokens from other users to do stuff for them when they are online, it’s just against the philosophy of the SAFE network.
It’s important to note that even if somebody used such a service, it wouldn’t put them at a more disadvantaged situation than what is the accepted norm today.
What’s better, however, and I’m sure we’ll see a lot of this, that people could keep apps (logged in with their auth tokens) running on their networked computers, that at the same time could serve as vaults as well.
I see this as a challenge, not as a limitation. It’s not a simple problem, otherwise it would’ve already been solved. With SAFE, we can start from a better point to address it, and I’m optimistic about finding good solutions from both of the privacy and security, and the user experience views.
I don’t think the low-level architectural decisions are actually limiting us in this regard, and I’m not sure the p2p aspect is relevant concerning the user experience because, from a user’s point of view, that aspect is designed to be transparent: the network looks like a huge, very secure, very private storage server (among other things.)
I agree about the internet, but I see it less as a mistake as a simple result of how it was born and how it developed over the years. Now, however, we’re starting with the wisdom of hindsight, so let’s use it well.
As I see, MaidSafe is currently busy working on the more fundamental technical aspects of the system, the things that will make all what we’re talking about possible. Let’s not forget that SAFE does have a built-in identity system, though a rather flat one. But, that’s fine: at the vault level, it doesn’t matter how the identities are structured, or if they are structured at all.
While they are working on making this thing happen, we can try to figure out some ways to go about these other issues. We could, for example, fork the Authenticator to implement a proof of concept for an identity system that supports personas.
As the project moves ahead, I expect that MaidSafe as well will start looking more into these questions, and then we’ll see them participate in these discussions more.
It seems some are conflating Public IDs and accounts.
From my understanding most of the above ideas can be implemented with the current concept of SAFE.
One account can have many multiple ID’s (many public & many private).
It is up to the APP design to how it chooses which ID to use
The user authorises the use of an ID
Noone else can claim the ID without the keys
A person can have multiple accounts each with their own set of IDs
I am sure an authenticator/whatever can be made to make it easy to swap accounts securely
In my estimation most of what is discussed is more convention/use-case and not setting anything into stone. SAFE will accommodate most when its functionally. Any limits on IDs now is for testing.
Last time I looked it was the “one account, one public ID” model, but I agree: it doesn’t have to stay like that. I feel like using different accounts for different public IDs is cleaner, but the access tokens are for specific folders, so apps could indeed be given access to the different personas securely without separate accounts as well.
Yes, I think so, too. It’s just that the project is not there yet. Also, the network provides us with all the low-level tools necessary to implement any kinds of model (I think), so we can do so if what we get is not what we’d like.
It will not stay like that. The concept of throwaway IDs (ones you register and never use again) was/is fundamental to the purpose of IDs (public or private). For Example You will have an ID for your wallet and it may not be the same as any other ID you have
Ah I will have multiple accounts for different aspects of my on-line experience. Each account can then have multiple IDs for various reasons. Throwaway (anonymity) is one, social/private is another.
Very much so, discussions are good. I would hate to see a system (SAFE) being constrained to a particular use-model. I guess I was trying to say that SAFE will allow many use-models and lets discuss them without trying to constrain SAFE to any one of them,
Mind you I don’t think anyone here was trying too but I did get the impression that some thought that was the purpose of the topic and so I wanted to voice that we are free to choose.
Also consider SQRL type Id’s as well here. So you have a master random string. Use the hash of that plus a purpose (say email ro visit to each website). Then take that purpose and generate keys just for that.
i.e.
email → Seed ed2559 kepypair with SHA3(sec_str + email)
safe://site1 → Seed ed2559 kepypair with SHA3(sec_str + site1)
safe://site2 → Seed ed2559 kepypair with SHA3(sec_str + site2)
In this way all the account needs to do is keep the master secure string (sec_str) and for each use case recreate the keys it used for that purpose.
In terms of account keys then we have not concluded that, so far the past discussions were along the lines of create 3 at any one time. These can be replaced but limit to 3, I am not sure there is a need for any limit at all, but we will see, some folks would just try and run mental scripts to capture all ids they can (of course you could not as 2^256 is a lot of keys )
The client manager group can limit these, but we are not convinced it should limit at all really. It’s a simple technical thing though, the political/commercial/user part is harder to fathom. For us in house the discussion has not even happened as we are to focussed on deeper issues right now. This is where the community helps us bashing the ideas around though.
[Edit} Another thought though, the most private wallet would be an id but not a public id at all. Just a keypair you don’t even publish the public key of at all. (brainstorming)
Good discussions here I appreciate everyone’s perspectives. I would love, if in response to any of my questions or opinions, anyone points out gaps in my knowledge that lead me to an ah-ha moment where something starts to seem clearer or makes more sense. I certainly don’t want anything I am saying to be perceived as just argumentative - that certainly is not my intent.
My concerns mostly originated when I started looking at the demo apps from Alpha one, and the fact they all asked me to create a new alias to use them. Why doesn’t my MaidSafe account have an alias and/or other identity data associated with my account? Right now it seems like the only information an app gets about me is a unique hash? How are applications going to share data and inter-operate if every one of them has to create and manage a separate user profile from scratch? Isn’t that the same mess we are already in?
I was sort of drawn to the vision of MaidSafe under the description that I owned and controlled my data, and I decided who to grant access to it, and I could see and revoke that access anytime. Having to create separate accounts and log in and out of separate accounts in order to share sub-sets of my data with other people or applications isn’t how I saw that working. In my mind, the separation between work and personal, or between my doctor, and soccer club isn’t a completely separate vault, it is more that I have a big collection of data, and I choose what to share between them. I certainly don’t share all the same information with my doctor that I share with my employer, but I do share some of that data, and I don’t want to duplicate it across separate accounts/vaults?
With the imminent release of stable at-home vaults, the new authenticator, and mutable data API, it seems like the SDK for building applications is going to stabilize. As someone looking to make a significant investment of time and energy into building applications for MaidSafe, I would very much appreciate in seeing (and participating in) some application architectural patterns and best practices, and some interoperability use cases being shared within the community between developers.
What would that sort of collaboration look like? Are discussions in the forums the best place for that the happen? Does anyone see a need for developers to organize specifically around patterns in the near future?
Forgive me if much of this has already been discussed over the long history behind MaidSafe, I am just trying to bring myself up to speed and it seems much of the things I am concerned about are still up in the air with regard to where MaidSafe is currently at.
Remember the apps we released are demo, we tried very hard to state these were not apps they were demo’s (we did not even put a reply button on the messaging app).
So you create a public Id and can register services/web sites etc. against that. However you decide on that name, not us and it’s not deterministic. It’s also not limited to a single Id. So you should as a user of the system have complete control over these Ids (kinda like DNS today, but you own all of it).
Registering apps is the way the authenticator recognises your local/web apps etc. and that’s also under your control to accept/deny/revoke at any time.
I understand - I don’t mean to come across as just critical. As someone learning, I looked to those applications as the only examples available of application architecture and how to design data structures. It spawned as many questions as it did answers.
Well founded critique is good, so don’t worry at all, it’s all good and we need to know where we are poorly communicating the system as it is right now. All good
@arsnebula Chris, for me your contributions come across just fine, so please continue because I think your fresh take is helpful, certainly to me.
@Tim87 your long response to Chris’ post was awesome. I can’t believe it had zero likes - by the time I got to the bottom (there were ten follow up posts on this topic) I wanted to give it a and ten likes.
@neo I’m not trying to constrain anything with my input, sorry if it came across that way. On the contrary, I was trying to ensure we didn’t kick off by establishing conventions which might well stick, without thinking things through in terms of what’s best for everyone. Let’s the games begin!
I’m loving this discussion. You guys are all great thinkers and way ahead of me in terms of concrete ideas. Enjoying my I hope to have something useful to add too at some point!
I haven’t read all the thread so this may already have been proposed. I think there should be a public ID and a default username. I assume that a mechanism is possible to implement that allows users to only have to sign in once to the entire SAFE network, and that granting access to apps can be done with a simple click on a button (without having to enter passwords etc for each app to sign in to).
As a hypothetical example, I have the public ID 940e22838cd06ab8e3c532f84a1f2f and the default username Anders.
The public ID is unique, while the default username is not (and can be changed without affecting the public ID). So in the example there can be hundreds of users with the default name Anders. This prevents name squatting and end users from being unable to use the usernames they want. And it’s convenient to use in apps since the default username can automatically be used by the app when the user signs in. Plus possible option to change the username on a per app basis (implemented by the app developers). And app developers can choose to enforce unique usernames if they want to on the app level.
but I did get the impression that some thought that was the purpose of the topic and so I wanted to voice that we are free to choose.
and ten likes.