User stories for web3.storage signup. Here are the technical diagrams.
Visits web3 storage site after recommendation from trusted colleauge. Reads a blog post and decides to try a tutorial. During the tutorial the software prompts for an email address for verification. When the user clicks the link in the email, the website opens into the developer console, with a welcome message.
The user switches back to their code editor and continues with the tutorial, creating some uploads on the command line. As they work, the uploads appear in the developer console. The user completes the tutorial, and goes home for the weekend.
Days or weeks later they need to upload a directory of files for a project, and remember that the console had a drag and drop target that advertised itself as working with files large and small. They visit web3.storage, click the Console link, and are prompted for an email address to login. (Again they receive an email and click the link to get into the console | alterantive future flow – they are redirected to a keyring/wallet website that manages their signing keys, and they decide which to link with this session). Their previous files are listed, and the upload drag and drop target is visible.
They drop the directory of files on the target, and see the files appear in the list view. Browsing into the upload they are satisfied, and send the URL to the other members of the project. On monday they are starting new app, and the tutorial made the SDK look really easy. The developer recommends web3.storage to the team, and on the strength their exprience with the last projects file sharing experience, and after a glance at the w3ui code sandbox, they agree to look into the API as a team.
The team works through the tutorial together, and then talks about how the API might help not only with uploads, but also user identity and access control (it looks compatible with the new Bluesky thing, which is interesting.) When the team hits a tough question, the lead developer joins the web3.storage Discord channel and works directly with our team and community to learn more about the platform and improve the solution architecture.
The team decides to ship with a user-paid model because the data volumes are large and many users will have already uploaded a photo gallery, so it’s better to work with user owned accounts. As users install the app, they are prompted to log into web3.storage with their email address or keyring/wallet. In this way, they can reuse accounts across apps, and grant only the right capabilities to the apps.
There is a screen where the user is prompted to choose which “space” to run the app in, or to create a new space. This screen is part of the default flow from clicking a web3.storage email verification link. It may be attributed to the keyring/wallet function, and phrased to reflect the user’s control over their own data / keypairs / spaces. The app can then read and write data in that space, and work with other apps that are interested in the data. Once the app is launched in its space the user doesn’t need to interact with web3.storage UI again, except if they get an email about payment required.
An app user can start using web3.storage apps in the same account on a new device. When the user launches the app / visits the site, they’ll be prompted to sign in via email. If the email address is the same, when they click the verification link, they’ll have their existing spaces listed, and can select the same space this app is running in on the original device.
If the user of an app that has been storing into a user-paid space wants to point another app at that space, it’s easy. The signup proceedure would feel the same (enter email, click link) then the user would select the existing space. The new app would load up with access to that space. The UI could offer distinct read / write / query /compute capability control for advanced users (not needed for MVP.)
If a user loses access to all their devices, they can gain access from a new device by signing in with their email and clicking into it. (Post-MVP there may be an option not to enable email recovery, in which case you can only recover based on delegating from existing device access. If you lose all your devices you can’t recover the account without email recovery.)