Direct copypasta

DESIGN.md

@@ -26,3 +26,136 @@ The two user types are 1) developers building apps, and 2) early adopters who wo
 ### App Accounts
 
 These are accounts that use the ODD SDK WebCrypto API, passkeys and/or WalletAuth blockchain accounts to generate DIDs automatically. The primary use case is for instant sign on progressive accounts. These accounts are the responsibility of the developer / app owner, who is charged for storage usage and other resources managed by the server. The developer (who has a Verified Account) has capabilities to view quotas for these accounts, and even delete misbehaving App Accounts.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+# DIRECT COPYPASTA
+
+**It is perhaps worth clarifying: this is meant as a jumping off point to open discussion and hopefully uncover any parts of the system that are unclear or misaligned. This is NOT a "write tables with these exact fields". Please do what makes sense since you'll have more context with boots on the ground.**
+
+## Goals
+
+* Every user gets an attached file system & subdomain out of the box
+* BYODUOS: Bring Your Own Domain, UCAN, Or Storage
+* Support app-namespaced users in addition to top-level Fission users
+
+### User Archetypes
+
+| Name  | Emoji | Role           | Core Need                                             |
+|-------|-------|----------------|-------------------------------------------------------|
+| April | 👩🏾‍💻    | App Developer  | Publish & manage apps                                 |
+| Terri | 🧑🏼‍💻    | Technical User | Publish files (e.g. backup their Desktop)             |
+| Usher | 👨🏽‍🎨    | App User       | Sign up for & use an app published to Fission's infra |
+
+### User Stories
+
+#### Near-Term Web Storage
+
+Terri wants to backup their Desktop, wants to be able to view their data online, and is going to write some tools to sync data between their devices. They open the Fission CLI and sign up for the service with their email, and registers the username `terri`. The server returns a 200 OK and a UCAN enabling their local DID to upload to storage that is accessible to read at (e.g.) `_dnslink.terri.files.fission.name`. They make a CAR Mirror request to upload data to the `terri.files.fission.name` file system (note: this is different from what we have today and is likely a good practice / solves a few edge cases that we've run into).
+
+#### Near-Term App Publishing
+
+April wants to launch an app on Fission's service. She goes to the Fission CLI, and signs up for the service with her email, and registers the username `april2023`. She's prompted to set up a Passkey (which will be her root DID). A WNFS is created, delegates a superuser UCAN to `did:key:zAprilPasskey`. April is prompted to register an app name or use the default (autogenerated `friendly-pink-dragon`), and select a directory that she wants to upload (`./`). The app directory is uploaded via CAR Mirror, and DNSLink at `friendly-pink-dragon.fission.app` is set.
+
+#### Aspirational FaaS Story
+
+Terri wants to register a function on Odd Functions. They go to the Fission CLI, and signs up for the service with their email, and registers the username `terri2023`. They're prompted to set up a Passkey (which will be their root DID). The Fission FaaS service then delegates 1000 credits to `did:key:zTerriPasskey`.
+
+#### Aspirational BYODUOS Story
+
+Part of what we want to enable _in the long term_ is the ability to bring your own storage or DNS. For example, you may want to update DNS at a separate provider like Cloudflare. You'll also note that NNS slots in really nicely for lots of related use cases here 😉 This is more "future", but useful for context.
+
+Operationally, when someone sets up a Fission account, we automatically grant them storage and a subdomain. The server itself behaves as if it's in a closed world. The front end SDK can later evolve to plug in other providers, like Cloudflare for DNS if they need to update on chnage. However, with the magic of [DNSLink], the user can very easily map their Cloudflare DNS to their `fission.name` record.
+
+Carol wants to sign up for the Fission service, but is bringing her own DNS (Cloudflare) but wants to still use our storage (not that this could be the opposite where she brings her own storage). She goes through the normal server setup flow (literally nothing changes here). She navigates to her application, and makes a bunch of changes to the data on her Volume. The SDK is configured with Cloudflare as the DNS provider via its plugin architecture, and after the ODD Volume returns successfully, the SDK sends a request to Cloudflare to update her DNSLink there. Cloudflare returns a 200. She loads her app on a second device, and all of her updated data is visible there.
+
+## Requirements
+
+Users come in two flavours: ~~vanilla and mint~~ Fission users and App users. The distinction is roughly "who is responsible for them?" (us or the app owner).
+
+## ERD
+
+Here is an _extremely loose, very hypothetical_ entity-relationship diagram modelling the database relationships.
+
+### Conventional
+
+#### Short Term
+
+![Screenshot 2023-03-31 at 15.37.49|180x500](upload://fdbG0GLuXJIwEqJdwp54y2L1UW2.png)
+
+#### Medium Term
+
+![Screenshot 2023-03-31 at 15.37.57|600x500](upload://89Suv4MuHTylwJPZ7zSn1p5pBiE.png)
+
+### Radical OCAP Design
+
+If we decide to lean more heavily into UCAN, we can pull some of these relationships out of the database, though keeping them aroudn certainly doesn't hurt in the case of recovery if they lose their UCAN. In this version, each resource gets its own DID, and delegates to the user. I suggest that this be kept as essentially a long term picture in your head as we can slowly make the databse vistigial.
+
+![Screenshot 2023-03-31 at 15.38.01|690x419](upload://wrhc1gOCYDqRx3DIeRuKro9TVfK.png)
+
+## Fission User
+
+The root of the system: Fission users. These are the people that we have direction relationships with. This anology only goes so far, but it's like setting up a root (AWS) IAM account. As such, we MUST record their username and email. They also get attached Volume storage out of the box.
+
+Unlike the current database, where this is all handled with database tables, we should explore this with UCAN (though we can still record this relationshiop if we want). For example, in DAG House's "Spaces" concept, the Space is gerated with a keypair, it delegates full control over itself to the user's DID, and deletes its keys. The advantage of this is that you don't have to look up the Space's "owner"; the root of the UCAN chain is the Space's DID. This also gets rid of that ugly polymorphic relationship in the ERD above :wink:
+
+## App
+
+* Owned by _one_ Fission user
+  * Extend permissions to others via UCAN
+* Gets a `fission.app` subdomain
+* Storage points at a path inside the owner's Volume
+
+## App User
+
+While we could arguably roll these into Fission users, the requirements are different enough in this revision that splitting them out makes sense.
+
+* Get a DNS subdomain at `<username>.<appname>.<domain>`
+    * Where the default `<domain>` is `fission.app`
+* Get assigned a Volume
+
+Unlike Fission users, we don't need to capture their email address or other info (we may later, but not for now).
+
+# Where We're Going
+
+It can be helpful to understand what's coming down the pipe. I can't emphasize strongly enough how this is not stuff to work on _today_, but having it loaded into everyone's brains is likely helpful for context :)
+
+**Emphasis: this is all future stuff**
+
+## Volumes
+
+As you may have heard, "pinning" is a terrible concept. It is much easier to think about a single logical "Volume" with a root CID. Volumes are likely going to include more info than a mutible pointer that holds a CID including geographic replication and storage quotas.
+
+## Name Name System (NNS)
+
+Part of the BYODUOS philosophy means that we can take the mutible pointers out of our managed DNS and move them to NNS. Of course NNS also manages things like DIDs, but for pointers to e.g. the latest WNFS, updating in NNS is a good source of truth (it's where the idea originated after all).
+
+How we'd interact with NNS is a whole other question. It's technically a separate system, though we'd run at least one node. Would we run a NNS gateway? Would we poll and update DNS as we track certain records? Would NNS look up records from our DNS? These are questions for when we get closer.
+
+## Interop
+
+We would like to seamlessly interop with other products and services in our orbit, such as Noosphere, Number0, DAG House, and Bacalhau. Being able to support DIDs generated by them, or transparently have them (e.g.) use us for DNS or us use them for storage would be helpful.
+
+# Links
+
+* https://talk.fission.codes/t/fission-accounts-and-app-owned-logins/4477
+
+[DNSLink]: https://dnslink.io/