When you visit an app powered by Fission, the “Sign in with Fission” is about giving the app permission to access your file system and store data there for you, related to the app.
To create a new Fission account, you can either visit the Auth lobby
auth.fission.codes, and a private key is created in your browser using the WebCrypto API. We ask for a unique username, and also an email address to verify.
Or, you can download the Fission CLI and create a new account on the command line, where a private key is placed in your home folder. This is familiar to developers we’ve surveyed that use Github. This private key is usually never changed until the developer moves to a new machine, and then searches for how to create a Github key
In the CLI case, we assume the desktop operating system is secured by the user, as this is the pattern used for Github and related approaches.
For the browser, we are relying on the WebCrypto API for the same use case. Once the key is resident, you are “logged in”.
We still don’t share any information when browsing to an app (we could, like username). “Sign in with Fission” takes you to the Auth lobby, much like an OAuth flow (This app would like to tweet on your behalf), or a permissions pop up on mobile (App X would like to access your Photos) to let you know what permissions the app wants.
Since we’re file based, we have some basics:
- The default, non optional permission is access to an “App folder”
- This means the app can write some basics, which might be as basic as some user preferences
- Dropbox has the concept of an App folder
- MacOS has a
- This is handled transparently on mobile operating systems
- The app can ask for a different private, encrypted path to write to
- The current version of MacOS asks permission to read/write different folders, like “Downloads”, or “Documents”
- this is one way that multiple apps can share data / documents
- The app can ask for a public path
Public/My Public Quotes
- pushing things public on your behalf might be done “later” – when you understand what the app is publishing for you
- or, you could ask for all of these permissions all at once, if you think the user will accept them all at once
With that background, do we want to promote a “log out” button?
We don’t have “log out” when your Github private key is in your file system. We don’t have “log out” on iOS.
You do have logout on Windows and MacOS, which logs you out of the entire desktop. Either for security, or for switching accounts.
You kind of have log out with one or more Google Accounts on Android, but that can be a fairly destructive experience.
We do have multiple “People” in Chrome. Mostly there isn’t a “log out”. After a while, your account icon will display “Paused”, showing that you have to login again to access Google properties.
Install / Uninstall / Delete
I think of “logging out” – in the Fission context – as more like a destructive un-install. Going from app to app, you are always logged into your Web Native File System by virtue of the key being resident.
Visiting an app – like the Quotes app – and giving it permission, is a bit like an install. That Quotes data is resident and is ALWAYS yours. You can revoke permission to the app, so it can no longer write to its App folder – but the data remains yours, under your control.
So, that’s why I think “log out”, out of an individual app, like Quotes, doesn’t make sense.
If you go to “Quotes App 2”, and give it permission, it can prompt the user to point at existing quotes files.
What message/button/account do we want to turn “Sign in with Fission” into, once we’ve given an app permission once?
Right now, if you visit Quotes app again … you’re just logged in. It handshakes automatically, and you’re in.
A little badge icon that indicates you’ve connected this app? Optional. Not sure what it would do, other than guide people to the Auth Lobby so they can delete their key completely.
Note: I do want to see a list of all of the apps you’ve “installed” somewhere. This may be in Drive, which can then also act as a launcher. This is about “what apps do I use?” and could potentially also be used to do operating system like things – like setting a default Markdown editor.
You definitely will have this in a view in the Auth lobby, which will be focused on seeing what permissions you’ve given to which apps (so this is about Security / Account management).
If you are on a shared desktop machine (eg. a using a web browser at a public library), you want to “log out”. We should support this use case and make it clear to users how to do this.
Likely this can be done by the Auth Lobby, which can also show you who you are logged in as.
So, from an app, maybe “leave” or another command takes you to the Auth lobby – or to the Drive app – where we can explain to users that mostly they don’t need to log out, unless they are on a shared machine.
Developer Multi Account Testing
It can be useful for a developer to test different accounts / account sign ups. This can be done in incognito mode.
It’s somewhat inconvenient to create new accounts and/or continuously have to link existing accounts. This is also the reason (re-linking an account) for mostly not logging users out.
Other than also educating developers to go to Auth lobby to logout, what else should we do?
I don’t think we want to support multiple Fission accounts logged in at the same time. This adds simplicity for the main case of many end users – they only have to remember one account. Multiple accounts CAN be created, this just ends up being a more sophisticated, advanced use case.