docs: add-content #7
Conversation
vasco-santos
force-pushed
the
add-markdown
branch
from
5685006
to
6fe652b
Compare
License: MIT Signed-off-by: Oli Evans <[email protected]>
| Possible architectures of using web3.storage to upload | ||
|
|
There was a problem hiding this comment.
I would take this out
| Possible architectures of using web3.storage to upload |
| @@ -0,0 +1,138 @@ | |||
| # Architecture options | |||
There was a problem hiding this comment.
| # Architecture options | |
| # Architecture |
|
|
||
| - Client-server: You (the developer) own the Space, and your user uploads to your backend infra before you upload it to the service | ||
| - Delegated: You own the Space, but you give a delegated UCAN token to your user's Agent to upload directly to the service (rather than needing to touch the upload in your backend) | ||
| - (Most complex) User-owned: Your user owns the Space and registers it and they use it to upload directly with the service; if you want to instrument visibility into what they're uploading, you'll have to write separate code in your app for it |
There was a problem hiding this comment.
| - (Most complex) User-owned: Your user owns the Space and registers it and they use it to upload directly with the service; if you want to instrument visibility into what they're uploading, you'll have to write separate code in your app for it | |
| - (Most complex) User-owned: User owns the Space and registers it. They use it to upload directly with the service |
They won't pay for the storage, and it depends on the capabilities the service will have. I would leave these details out
| - Your user does not need a registered Space - just an Agent with a delegation from your Space | ||
| - w3up-client in the end user environment should have a unique Agent for each user, which should happen by default (since when w3up-client is instantiated it creates a new Agent anyway, or uses the one in local Store) | ||
| - From there, when your end user is ready to upload, they should request from your backend a delegation from your developer-owned Space to their Agent (which can be derived via [client.agent()](https://github.com/web3-storage/w3up/blob/main/packages/w3up-client/docs-Client#agent)) | ||
| - In your backend, you can call [client.createDelegation()](https://github.com/web3-storage/w3up/blob/main/packages/w3up-client/docs-Client#createDelegation) passing in the Agent object from client.agent() in your end user's instance, and passing through options? params to limit the scope of the delegation (e.g., store/add, upload/add, expiration time) |
There was a problem hiding this comment.
We should clearly mention that we do not recommend delegation with wildcard and only for what is strictly needed
| - You can serialize this using delegation.archive() and send it to your user | ||
| - The end user instance of the client should not need to call client.authorize(email), as it is not claiming any delegations via email address (but rather getting the delegation directly from your backend) | ||
| - Once your user receives the delegation, they can deserialize it using [ucanto.Delegation.extract()](https://github.com/web3-storage/ucanto/blob/c8999a59852b61549d163532a83bac62290b629d/packages/core/src/delegation.js#L399) and pass it in using client.addSpace(), and from there they can run any of the upload methods | ||
| - Note that this alone does not give visibility into which of your end users are uploading what; to track this, you'll probably need them to send you that information separately (e.g., once they've run upload and get back a content CID, you can have them send that CID to you for tracking) |
There was a problem hiding this comment.
there is also the option to create a space per user under your "account"? Which I actually would be expecting to read
There was a problem hiding this comment.
tracking as a separate request does not look so functional as an user can easily workaround this and use the delegation "off record" in the frontend
There was a problem hiding this comment.
plz open an issue or PR for this?
src/pages/docs/concepts/car.md
Outdated
|
|
||
| Working with Content Archives (CAR) files | ||
|
|
||
| When you upload files to web3.storage using the [client library](https://web3.storage/docs/reference/js-client-library/), your data is converted into a graph of data structures, which are then packed into a format called a Content Archive (CAR) before being sent to the web3.storage service. |
There was a problem hiding this comment.
Could this be a local link?
src/pages/docs/concepts/car.md
Outdated
|
|
||
| The [ipfs-car](https://github.com/web3-storage/ipfs-car) JavaScript package includes a command-line tool for easily creating, unpacking, and verifying CAR files. | ||
|
|
||
| To install it, you'll need [Node.js](https://nodejs.org/) - we recommend the latest stable version. |
There was a problem hiding this comment.
I would honestly get all these details out. They already are in the repo readme and when changed we need to bubble up these changes everywhere
License: MIT Signed-off-by: Oli Evans <[email protected]>
License: MIT Signed-off-by: Oli Evans <[email protected]>
License: MIT Signed-off-by: Oli Evans <[email protected]>
License: MIT Signed-off-by: Oli Evans <[email protected]>
License: MIT Signed-off-by: Oli Evans <[email protected]>
License: MIT Signed-off-by: Oli Evans <[email protected]>
Co-authored-by: Vasco Santos <[email protected]>
|
This PR now implements most of the content and navbar layout that was proposed in https://docs.google.com/document/d/1Y280tgNbrdb_MalxEFXpjm11SBBT2SdJwMPD6sqmm4s/edit#heading=h.7x0qpln8js0o The content needs refining, and some pages need completing, but I have normalised what we have so it's coherent, so other folks can jump in and build on it 
|
No description provided.