Skip to content

fix: errors in mermaid diagrams preventing it from rendering #45

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 12 additions & 12 deletions src/pages/concepts/architecture-options.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -17,9 +17,9 @@ In this set up, you (the developer) own the space, your users upload data to you
```mermaid
sequenceDiagram
participant User
w3up-client in backend-\>\>w3up-client in backend: Client set with Agent with delegation from Space
User-\>\>w3up-client in backend: Upload data
w3up-client in backend-\>\>storacha w3up service: Upload data
w3up-client in backend->>w3up-client in backend: Client set with Agent with delegation from Space
User->>w3up-client in backend: Upload data
w3up-client in backend->>storacha w3up service: Upload data
```

You'll need a registered Space, and your client in the backend to have a delegation to use the Space.
Expand All @@ -41,11 +41,11 @@ sequenceDiagram
participant w3up-client in user
participant w3up-client in backend
participant storacha w3up service
w3up-client in backend-\>\>w3up-client in backend: Client created with Agent and delegation from Space
w3up-client in user-\>\>w3up-client in user: Client instantiated with default Agent
w3up-client in user-\>\>w3up-client in backend: Request delegation with user's Agent DID
w3up-client in backend-\>\>w3up-client in user: Send delegation from Space to user's Agent DID
w3up-client in user-\>\>storacha w3up service: Upload data
w3up-client in backend->>w3up-client in backend: Client created with Agent and delegation from Space
w3up-client in user->>w3up-client in user: Client instantiated with default Agent
w3up-client in user->>w3up-client in backend: Request delegation with user's Agent DID
w3up-client in backend->>w3up-client in user: Send delegation from Space to user's Agent DID
w3up-client in user->>storacha w3up service: Upload data
```

Typically `w3up-client` will be running in your end-user's client code, as well as backend code that's able to generate UCANs that delegate the ability to upload and pass them to your users (e.g., `w3up-client` running in a serverless worker).
Expand Down Expand Up @@ -144,10 +144,10 @@ sequenceDiagram
participant User
participant Application backend
participant storacha w3up service
Application backend-\>\>User: Front end code that includes w3up-client
User-\>\>storacha w3up service: (If needed) Create Space and register it
User-\>\>storacha w3up service: (If needed) Use Agent email verification to "log in" to Space
User-\>\>storacha w3up service: Upload data using w3up-client
Application backend->>User: Front end code that includes w3up-client
User->>storacha w3up service: (If needed) Create Space and register it
User->>storacha w3up service: (If needed) Use Agent email verification to "log in" to Space
User->>storacha w3up service: Upload data using w3up-client
```

If you want your user to own their own Space, you'll typically be relying on the `w3up-client` methods to create a Space, authorize the Space, and authorize the Agent on the user-side; afterwards they can run any of the upload methods.
Expand Down
32 changes: 16 additions & 16 deletions src/pages/how-to/upload.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -70,10 +70,10 @@ A new client can claim access to their existing Spaces by validating their email

```mermaid
sequenceDiagram
Client-\>\>storacha service: Here is my email address and Agent DID
storacha service--\>\>Client: Please click the link to validate
Client--\>\>storacha service: Email address validated
storacha service-\>\>Client: Here is a UCAN attesting that your Agent DID belongs to your email
Client->>storacha service: Here is my email address and Agent DID
storacha service-->>Client: Please click the link to validate
Client-->>storacha service: Email address validated
storacha service->>Client: Here is a UCAN attesting that your Agent DID belongs to your email
```

You can use Storacha's email authorization flow to give permissions to your client. This can be good if your environment will be persistent (otherwise it would be prohibitive to click an email validation link every time the client is re-instantiated).
Expand Down Expand Up @@ -107,9 +107,9 @@ await client.setCurrentSpace('did:key:...') // select the relevant Space DID tha

```mermaid
sequenceDiagram
Developer-\>\>Developer: Create Agent private key and DID
Developer-\>\>Developer: Delegate UCAN from Space to Agent
Developer-\>\>Client: Here is my Agent private key and UCAN delegating permissions
Developer-->>Developer: Create Agent private key and DID
Developer-->>Developer: Delegate UCAN from Space to Agent
Developer-->>Client: Here is my Agent private key and UCAN delegating permissions
```

An option that works for any backend environment is for a developer to create and provision a Space, and then delegate access to a different Agent DID that will be used by the client. This is especially useful if you're using the client in a serverless environment (e.g., AWS Lambda).
Expand Down Expand Up @@ -170,8 +170,8 @@ There are two main options to getting content into your Space:

```mermaid
sequenceDiagram
User-\>\>Application Backend: Upload data
Application Backend-\>\>storacha service: Upload data
User->>Application Backend: Upload data
Application Backend->>storacha service: Upload data
```

You are already set up to upload using your client instance as data becomes available to your backend - you can call `uploadFile` or `uploadDirectory` with it.
Expand All @@ -194,13 +194,13 @@ In the example above, `directoryCid` resolves to an IPFS directory.

```mermaid
sequenceDiagram
participant User
participant Application Backend
participant storacha service
User-\>\>User: Client instantiated with default Agent
User-\>\>Application Backend: Request delegation with user's Agent DID
Application Backend-\>\>User: Send delegation from Space to user's Agent DID
User-\>\>storacha service: Upload data
participant User
participant Application Backend
participant storacha service
User->>User: Client instantiated with default Agent
User->>Application Backend: Request delegation with user's Agent DID
Application Backend->>User: Send delegation from Space to user's Agent DID
User->>storacha service: Upload data
```

Your backend instance can also be used to delegate upload permissions directly to your user to upload. The code snippet below shows an example of how you might set up a client instance in your application frontend and how it might interact with your backend client. You can see how the frontend client Agent DID is used for the backend client to delegate permissions to; from there, it will be the frontend client that will call the `upload` method.
Expand Down
Loading