Break out into multiple files

fission-codes · Sep 24, 2023 · 6e36d03 · 6e36d03
1 parent 6dc30d1
commit 6e36d03
Show file tree

Hide file tree

Showing 2 changed files with 26 additions and 30 deletions.
diff --git a/DESIGN.md → design/README.md b/DESIGN.md → design/README.md
@@ -1,6 +1,9 @@
-# Software Architecture and Usage Design Goals
+# Software Design Documentation
 
-The Fission Server is focused on providing and coordinating DID-based accounts and UCAN-based capabilities to different apps and systems.
+The Fission Server provides and coordinates DID-based accounts and UCAN-based capabilities.
+
+
+to different apps and systems.
 
 ## Usage
 
@@ -15,32 +18,6 @@ We _may_ support multi-tenant in the future (hosting multiple "Login with Brand"
 * Management of attached WNFS storage, including updating `_dnslink` entries for every account.
 * Direct DNS capabilities, set up other DNS providers as secondaries
 
-## Terms & Definitions
-
-### Verified Accounts
-
-These are accounts in the server-managed namespace who have a verified email. They have a relationship with the entity running the server -- which might be for a business, an app, or a service provider. These accounts are responsible for their apps, app accounts, storage used, and so on. It uses a managed username that creates friendly subdomains within the server.
-
-The two user types are 1) developers building apps, and 2) early adopters who would like to have their own _Login with Brand_ account. Both have a username under a default subdomain e.g. _boris.odd.name_.
-
-### 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
 
 
 
@@ -49,8 +26,6 @@ These are accounts that use the ODD SDK WebCrypto API, passkeys and/or WalletAut
 
 # 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

diff --git a/design/dictionary.md b/design/dictionary.md
@@ -0,0 +1,21 @@
+# Dictionary
+
+| Term               | Definition |
+|--------------------|------------|
+| [App Account]      |            |
+| [Verified Account] |            |
+
+### Verified Account
+
+These are accounts in the server-managed namespace who have a verified email. They have a relationship with the entity running the server -- which might be for a business, an app, or a service provider. These accounts are responsible for their apps, app accounts, storage used, and so on. It uses a managed username that creates friendly subdomains within the server.
+
+The two user types are 1) developers building apps, and 2) early adopters who would like to have their own _Login with Brand_ account. Both have a username under a default subdomain e.g. _boris.odd.name_.
+
+### App Account
+
+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.
+
+<!-- Internal Links -->
+
+[App Account]: #app-account
+[Verified Account]: #verified-account