I love the “showroom” idea to have a built in place to check out apps and see ratings. Just makes sense.
I personally prefer AppLauncher I think it’s simple, sounds good, and makes sense. I do also like authenticator. But i think it’s spot on so far from my perspective!
I follow your logic for keeping it to authentication - we’re both programmers so it is logical 
- but my suggestions are about user experience, and I don’t see this featuring in your analysis.
User wants to do stuff on SAFE.
Start thing to get access and log in.
[Here is the split: a) Launcher/Authenticator, followed by… find and start LifeStuff a g a i n, or b) Immediate access to Core SAFE Features (drive/comms/wallet/etc) ]
Since 99% of the time users want a core function, I think it’s worth considering having those things immediately available within the first screen following authentication. Essentially this turns LifeStuff into the Launcher I think.
There’s no reason not to provide an alternative authenticate-only launcher, for people who prefer to see … what? I’m not clear on what the current Launcher UX is planned to be once authenticated. To launch apps, presumably you at least see Drive anyway? Or not?
1 Like
I get what you’re saying Mark, however it doesn’t have to be that complicated(I mean the find and open the App part after logging in to launcher). I’d call that bad UX myself too but we don’t have to start bundling stuff in the main app to prevent it either. Maybe this image could help. This isn’t from the latest iteration, just for a rough idea:
Consider that’s what you see when you login. So you don’t leave the App to launch “Getty Images”(It’s one of the app in the image).
Now the argument could be “Oh I might have 100’s of apps and scrolling to pick one might be annoying”. - We can cater for this too by providing a startup app list which gets launched when you login to the launcher. Thus we can achieve the objective of “I Login and with no other interaction have LifeStuff up and running”. A minor positive here (just IMO btw), if someone doesn’t prefer LifeStuff(maybe they don’t like a UI and want to use a command line client), they can just as easily have a LifeStuff alt app in the startup list and not lifestuff. So people can cater their experience how they see fit and we keep it light in the “included package”
8 Likes
I actually REALLY like this idea.
It made it a whole lot less confusing for me and made me understand it.
“Client” is definitely the best word to use here.
It is your main window to the SAFE network, and the only place you should enter your login credentials.
Right???
Yeah, I think that client is a good word if only for its familiarity. Even if how it works on maidsafe is a little different than the technical definition of a client, labeling it that communicates the need for people to have if not this specific client at least SOME client between their credentials and the apps they interact with.
I just went out to the link at the top of the page and looked through github. The UI mockups are all located here.
1 Like
Hi everyone,
I think something that could be interesting is to use the startup app (not the Launcher but the default app inside it) as a way to teach the fundamentals of the system. In other words, the relation between the quantity of data you can upload, the vault and the currency. My reasoning is that for most people, the concept of having to give to get is, sadly, a very alien one. What people are used to is: create an account, sign an agreement they don’t read and use a service they don’t need to pay for.
Here, I’m not talking about a tutorial with arrows and popups all over the place. Just a very simple app with the three core element in it.
- A window with a file hierarchy to put files in.
- A progression bar with the quantity of data you can upload and your current balance of Safecoin (hideable)
- And a very sexy looking button to start a vault.
When you add a file, the progression bar fills up nicely and when it reaches 75% a small notification invites you to start a vault to get more space. Starting a vault would explain the concept in very simple term.
After that, people are free to use any other app instead, this one is just to get them started.
On a side note, I would love to see a traditional terms and conditions page with a single line in it. Something like, “Click yes to accept that your data will be 100% yours and 100% private. Welcome to MaidSafe”.
Anyway, keep up the good work, I can’t wait to see the progress on this.
@Viv, whatever the function may be called, it just occurred to me that we must be talking about a default behaviour at the API level, right?
You guys put a LOT of thought into this idea. I had to read it several times to understand, visualize, and comprehend how it all fits together. Unfortunately, I’m now lost. Please correct me if any of the following is wrong or has changed.
Accessing the Network
The MaidSafe client is a program used to log in to and access the SAFE Network. After starting the MaidSafe client you are asked to provide login details. A user’s wallet is created when they join the SAFE Network.
http://systemdocs.maidsafe.net/content/what_it_is/costs_of_using_the_safe_network.html
http://systemdocs.maidsafe.net/content/what_it_is/wallets.html
- Running the MaidSafe client establishes a bootstrap connection to the SAFE Network, and creates an account/identity, including a Safecoin wallet address.
According to the OP, the SAFE App Launcher will handle credentials but NOT kick start the SAFE Network. If that is true, will we have 2 login screens? 1 from the App Launcher and 1 from the MaidSafe Client?
Or has it changed to this…
- start the MaidSafe Client “connection only” to the SAFE Network
- then run the SAFE App Launcher to “create account, login” then run apps.
If I understood correctly, there is flexibility in separating the two processes. Devs can customize Alternative App Launchers UI without interfering with the MaidSafe Client. You guys are so modest.
Where does a Vault fit in? Is it part of the MaidSafe client?
I assume a Vault is established on MaidSafe client side so it can run in the background, without having to be logged into the SAFE Network.
I’m not a security expert, but when I see PIN KEYWORD PASSWORD all I can think of is hard/software keyloggers. So maybe this might be a solution for now:
Because the SAFE App Launcher is open-source, what’s stopping the NSA to create their own version and collect people’s credentials, through pretty apps? Is there a mechanism on the SAFE network that prevent apps from stealing credentials?
BTW I don’t mean to sound negative, because it’s you guys who’s doing the heavy lifting and much respect for that. But maybe thinking like an attacker of the SAFE network is the best way to secure it and keep it SAFE.
Keep up the good work
1 Like
How about creating apps. Will it be like some sort of Chrome-app? Using Javascript, CSS, HTML etc. to make a weblike app running one the SAFE-software? I hear people talk about creating apps using Python etc. but isn’t there a risk to that? Like some corrupt people create a .exe file which connect you to SAFE using an API, but which steals some of you info while you log in.
Another question that comes up is about the owner of an App. What if someone creates something like SAFEtube, get’s over 10.000 people uploading videos etc. and than finally decides to delete his App? Will everything be gone? And what about someone creating an App and forget his login etc. This “ghost” app will be online forever, seen (and maybe used) by a lot of people but without an owner…
My understanding is that creating an app that is meant to run inside the app launcher will have to be done in a specific way. I’m not sure if they have settle for any particular language yet like html, javascript or something else.
About safety, executing a malicious exe file could compromise your computer and there is nothing MaidSafe can do about it or should try to do about, it’s not its job. As a user your responsability toward your own security is to be sure that you only download program from legit source. Note that there is nothing new here.
About SAFETube, my guess is that if someone were to build this app he would do it in decentralized manner where everyone keeps their videos and only use the app to share them. If the app goes offline, everyone would keep their videos and just use another app to share them. They might lose all meta data like “views”, “likes” and comments but the video would remain theirs.
Ghost app, that’s an interesting one and we will probably see a lot of them
2 Likes
Actually, this is not accurate. Their are 3 types of apps, one that runs inside the launcher, one that runs outside of it but use the launcher to handle the credential and apps that run completely independent of the app launcher. The first one will have to be made in a very specific way compatible with the launcher. The second and third kind can be written using any language. Again that’s my understanding, I hope it helps.
1 Like
I doubt that the first version of the application will support containers directly. I’m hoping that the team can find a way to squeeze in a button to reveal the token that would be passed to the app - that way advanced users could run certain apps under different OS accounts, or inside of a container. I hope things progress enough where the container concept can be handled directly by the Launcher, I think it would be the basis for the “SafeOS” that keeps getting mentioned.
Its probably best that you read about containers. You can limit the amount of processing time, memory, and hard-drive capacity in a container. You can give an entirely separate filesystem, process list, and network stack in a container. So applications launched in a container wouldn’t be aware of other applications running, which would make impersonations even more difficult.
Only a single login is necessary. @Viv was referring to semi-technical nature of how this is being implemented. Currently the system requires a routing table per identity, and there isn’t going to be a global routing table per identity. Think of this in terms of OS vs application. For IP, the OS manages the connections, and so a single routing table exists for all applications. Since we aren’t doing OS level integration (at least not yet), having a consistent routing table per identity across all applications would mean a separate process/library that handles all communications for SAFE apps. We are not doing that model intially; each application will have to “connect” to the network separately (have its own routing table), even if multiple apps are using the same identity.
There have been some discussions (perhaps more than I know) of making a single process that handles these communications. This is a bit more involved, and I’m not sure of the priority.
Thats a good question, that I forgot in all of this. I know Drive will be moved out of the top-level project, and considered “just another app”, but the vault is a bit different in what it needs to do … @anon86652309 ?
I don’t think there is much we can do to prevent this. Giving applications your SAFE user/pass is always going to be risky. Running applications that can log keystrokes across all applications is always going to be risky. This (hopefully very simple) application will limit a single process to ever having your user/pass in memory, and will prevent you from locally having to login to each app. I still suspect that the majority of the users would be better with a browser extension for SAFE, simply because a malicious app can do less damage (since its running through the browsers “contained” environment). Unfortunately, “Free” apps of questionable origin and no available source code seem to always tempt a certain amount of users.
I’ve thought this as well, but I’ll leave this aspect to the user experience people.
I think this is already been covered, but … You still have to be careful about the applications you run directly on your machine. The team is looking into a Firefox browser extension, which would reduce some risk since the code is running in the browser and not the direct OS. Hopefully this would work on all platforms consistently. I’ve also discussed containerization as a possibility, but I think preventing a keylogger would still be tricky (especially if the container had permissions for UI libraries). If the token button is implemented (see above), we should be able to pass credentials into a virtual machine - but that would require port listening on more than just localhost (which has other security implications).
This is best explained by the crazy Gnu people.
And whether the data backing the app is gone depends on the implementation. If content was stored by each uploader (so that they actually have complete control over their data), there is nothing the original app owner can do. If the content is fed into a single account controlled by the app developer, it could in theory be deleted. The SAFE API will keep a history by default, so a simple “delete container” isn’t actually going to purge everything from the network. You’d have to cycle through the max history limit to do that.
There are really only two cases. Even in the container scenario, the application is running as a separate process, but inside of a container created by the launcher.
7 Likes
Are we talking about docker style containers here? I actually spent the weekend researching them for a work project (impressed, I have to say!). If we are talking about these, then I can definitely see the benefits (and limitations for non-Linux systems).
Obviously if SafeOS becomes a reality, I assume it would be Linux based and could facilitate docker containers. Perhaps SafeOS could even be based around CoreOS?
Yes, it would use kernel namespaces and cgroups. Docker/LXC are the two most prominent projects that facilitate the usage of those technologies.
1 Like
Thanks @Viv. I can see I’m flailing because of too little understanding of the proposal - implementation and UX.
I need to know more before I can comment properly. Having said that, I think having the main apps appear in that first window - locked in the same initial position unless explicitly moved by user - achieves what I was aiming for, with auto starting selected apps a further step. Though it all depends on how long, how many clicks, and how many visual context switches it takes me to go from entering login, to actually doing work.
I’d like to offer feedback or ideas if there is an opportunity, particularly while there’s time to influence.
This is a vital part of the whole project, and I’m experienced in this area so feel free to throw ideas or story boards my way if you can bear yet another voice. 
No hard feelings if not, but I will say what I think later 
Naming
Regarding naming, i don’t like “authenticator”. It’s accurate, but not helpful to Joe public IMO.
People seem to like “Client” but that too is quite geeky. So I’m wondering about equating “launcher” with the network by naming it “SAFE Network”, or “Start SAFE”, or “SAFE Start”, “SAFE Desktop”, or even just “SAFE”.
I can imagine with popular adoption it will be just called “safe” - “Have you got SAFE?” … “Did you see that new app, secure storage, it’s called SAFE?” etc. So maybe take a risk with just “SAFE” and once launched, the display just has “SAFE Apps” across the top.
I’m not sure what users think their phone/pad app tile area is called, if anything, but I’m not sure “Desktop” is appropriate for all devices?
2 Likes
I like more “SAFE Start” than “SAFE launcher”
Maybe can use a symbol like “SAFE 
” or a word who indicate openness like “open SAFE” or “easy SAFE” or “SAFEeasy”.
Only brainstorming…
1 Like
The SAFE no-client, anti-client, or pseudo-client, null-client, un-client,
I like “SAFE Start”
2 Likes
+1 for “SAFE Start”
3 Likes