From 5049121ed38ba89b70003aff734da25098b5178c Mon Sep 17 00:00:00 2001 From: Amy Waliszewska Date: Tue, 6 Aug 2024 12:23:32 +0200 Subject: [PATCH] Update documentation from web3.storage to storacha --- src/pages/docs/concepts/_meta.json | 4 +- .../docs/concepts/architecture-options.mdx | 20 +++++----- src/pages/docs/concepts/car.md | 24 ++++++------ src/pages/docs/concepts/content-addressing.md | 22 +++++------ src/pages/docs/concepts/filecoin-storage.md | 6 +-- src/pages/docs/concepts/ipfs-gateways.md | 2 +- src/pages/docs/concepts/podsi.mdx | 14 +++---- src/pages/docs/concepts/ucan.md | 22 +++++------ .../docs/concepts/ucans-and-web3storage.md | 10 ++--- src/pages/docs/concepts/upload-vs-store.md | 20 +++++----- src/pages/docs/faq.md | 18 ++++----- src/pages/docs/glossary.yml | 16 ++++---- src/pages/docs/go-w3up.mdx | 8 ++-- src/pages/docs/how-to/ci.mdx | 10 ++--- src/pages/docs/how-to/create-account.md | 8 ++-- src/pages/docs/how-to/create-space.mdx | 8 ++-- src/pages/docs/how-to/filecoin-info.mdx | 2 +- src/pages/docs/how-to/http-bridge.mdx | 30 +++++++-------- src/pages/docs/how-to/list.mdx | 12 +++--- src/pages/docs/how-to/receipts.md | 2 +- src/pages/docs/how-to/remove.mdx | 10 ++--- src/pages/docs/how-to/retrieve.mdx | 14 +++---- src/pages/docs/how-to/upload.mdx | 38 +++++++++---------- src/pages/docs/how-to/w3name.mdx | 8 ++-- src/pages/docs/index.mdx | 4 +- src/pages/docs/privacy-policy.md | 8 ++-- src/pages/docs/quickstart.md | 20 +++++----- src/pages/docs/service-level-agreement.md | 18 ++++----- src/pages/docs/terms.md | 24 ++++++------ src/pages/docs/w3cli.mdx | 8 ++-- src/pages/docs/w3up-client.md | 8 ++-- 31 files changed, 209 insertions(+), 209 deletions(-) diff --git a/src/pages/docs/concepts/_meta.json b/src/pages/docs/concepts/_meta.json index da64262..0cd6d91 100644 --- a/src/pages/docs/concepts/_meta.json +++ b/src/pages/docs/concepts/_meta.json @@ -1,5 +1,5 @@ { - "ucans-and-web3storage": "UCANs and web3.storage", + "ucans-and-storacha": "UCANs and Storacha", "content-addressing": "Content-addressing", "upload-vs-store": "Upload vs. Store", "architecture-options": "Architecture options", @@ -13,4 +13,4 @@ "ucan": { "display": "hidden" } -} \ No newline at end of file +} diff --git a/src/pages/docs/concepts/architecture-options.mdx b/src/pages/docs/concepts/architecture-options.mdx index 9ee24d1..a40de96 100644 --- a/src/pages/docs/concepts/architecture-options.mdx +++ b/src/pages/docs/concepts/architecture-options.mdx @@ -1,10 +1,10 @@ import { Callout } from 'nextra/components' -# Possible architectures using web3.storage to upload +# Possible architectures using Storacha to upload UCAN opens up a number of options in how to integrate with w3up: Should you, the developer, own the Space? Should you delegate permissions to your users? Or should your user own their own Space? Broadly, there are three ways to integrate: -- **Client-server**: You (the developer) own the space, your users upload data to your application server, and you upload it to web3.storage from there. +- **Client-server**: You (the developer) own the space, your users upload data to your application server, and you upload it to Storacha from there. - **Delegated**: You own the Space, but you provide your user with a delegation that allows them to upload directly to the service. This avoids proxying the upload through your backend (no egress from your infrastructure). - **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. @@ -12,14 +12,14 @@ In the How-tos section of the docs, we focused on the first two options, as they ## Client-server -In this set up, you (the developer) own the space, your users upload data to your application server, and you upload it to web3.storage from there. +In this set up, you (the developer) own the space, your users upload data to your application server, and you upload it to Storacha from there. ```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-\>\>web3.storage w3up service: 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. @@ -40,12 +40,12 @@ In this set up, you own the Space, but you provide your user with a delegation t sequenceDiagram participant w3up-client in user participant w3up-client in backend -participant web3.storage w3up service +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-\>\>web3.storage w3up service: Upload data +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). @@ -144,11 +144,11 @@ In this set up your user owns the Space and registers it and they use it to uplo sequenceDiagram participant User participant Application backend -participant web3.storage w3up service +participant storacha w3up service Application backend-\>\>User: Front end code that includes w3up-client -User-\>\>web3.storage w3up service: (If needed) Create Space and register it -User-\>\>web3.storage w3up service: (If needed) Use Agent email verification to "log in" to Space -User-\>\>web3.storage w3up service: Upload data using 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. diff --git a/src/pages/docs/concepts/car.md b/src/pages/docs/concepts/car.md index ecb8265..f70d458 100644 --- a/src/pages/docs/concepts/car.md +++ b/src/pages/docs/concepts/car.md @@ -1,28 +1,28 @@ # Working with Content Archive (CAR) files -When you upload files to web3.storage using the 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. +When you upload files to Storacha using the 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 Storacha service. -For most use cases, you never need to know about this process, as the conversion happens behind the scenes when using the client library. However, you might want to know more about how to manipulate CAR files directly, especially if you're using `upload` and `store` separately in web3.storage. +For most use cases, you never need to know about this process, as the conversion happens behind the scenes when using the client library. However, you might want to know more about how to manipulate CAR files directly, especially if you're using `upload` and `store` separately in Storacha. ## What is a Content Archive? -The [Content Archive format](https://ipld.io/specs/transport/car/) is a way of packaging up [content addressed data](https://web3.storage/docs/concepts/content-addressing/) into archive files that can be easily stored and transferred. You can think of them like [TAR files](https://en.wikipedia.org/wiki/Tar_\(computing\)) that are designed for storing collections of content addressed data. +The [Content Archive format](https://ipld.io/specs/transport/car/) is a way of packaging up [content addressed data](https://storacha.network/docs/concepts/content-addressing/) into archive files that can be easily stored and transferred. You can think of them like [TAR files](https://en.wikipedia.org/wiki/Tar_\(computing\)) that are designed for storing collections of content addressed data. The type of data stored in CARs is defined by [IPLD](https://ipld.io/), or InterPlanetary Linked Data. IPLD is a specification and set of implementations for structured data types that can link to each other using a hash-based Content Identifier (CID). Data linked in this way forms a Directed Acyclic Graph, or DAG, and you'll likely see a few references to DAGs in the documentation for IPLD and IPFS. IPFS files are one example of IPLD data, but IPLD can also be used to access data from Ethereum, Git, and other hash-addressed systems. You can also use IPLD as a general purpose format for your structured data, sort of like a Web3-flavored JSON. See Advanced IPLD formats below for more information. -## CARs and web3.storage +## CARs and Storacha -When the web3.storage client and CLI pack up regular files into a CAR to store on IPFS, the CAR contains data encoded in the same format used by IPFS when importing files using the command line or other IPFS APIs. +When the Storacha client and CLI pack up regular files into a CAR to store on IPFS, the CAR contains data encoded in the same format used by IPFS when importing files using the command line or other IPFS APIs. This format uses an IPLD "codec" called [dag-pb](https://ipld.io/docs/codecs/known/dag-pb/), which uses [Protocol Buffers](https://developers.google.com/protocol-buffers) to encode an object graph. Inside the graph are [UnixFS objects](https://docs.ipfs.io/concepts/file-systems/#unix-file-system-unixfs) that describe the files and their contents. We do this client-side for a few reasons. -First, formatting everything on the client allows us to calculate the root Content Identifier for the data you're uploading before we send any data to the remote service. This means that you can compare the CID returned by the web3.storage service to the one you calculated locally, and you don't have to trust the service to do the right thing. +First, formatting everything on the client allows us to calculate the root Content Identifier for the data you're uploading before we send any data to the remote service. This means that you can compare the CID returned by the Storacha service to the one you calculated locally, and you don't have to trust the service to do the right thing. -Another reason to use CARs is to support large files, which would otherwise hit size limits on the web3.storage backend platform. The data in a CAR is already chunked into small blocks, which makes CARs easy to shard into small pieces that can be uploaded in batches. This also enables the web3.storage platform to get larger content into Filecoin deals. +Another reason to use CARs is to support large files, which would otherwise hit size limits on the Storacha backend platform. The data in a CAR is already chunked into small blocks, which makes CARs easy to shard into small pieces that can be uploaded in batches. This also enables the Storacha platform to get larger content into Filecoin deals. -CAR files are a format that pretty much any IPFS tool or implementation can interact with. You can export data from your personal IPFS node into a CAR file and upload it to web3.storage using `w3 up --car` or `client.uploadCAR`. As a result, we dive into the various ways you might interact with CAR files. +CAR files are a format that pretty much any IPFS tool or implementation can interact with. You can export data from your personal IPFS node into a CAR file and upload it to Storacha using `w3 up --car` or `client.uploadCAR`. As a result, we dive into the various ways you might interact with CAR files. ## Command line tools @@ -85,17 +85,17 @@ ipfs dag import path/to/input.car ### `ipfs-car` -The [`ipfs-car`](https://github.com/web3-storage/ipfs-car) package includes library functions for packing and unpacking files into CARs, using the IPFS UnixFs data model. The library includes the same functionality as the ipfs-car command line utility [described above](https://web3.storage/docs/how-tos/work-with-car-files/#ipfs-car). +The [`ipfs-car`](https://github.com/web3-storage/ipfs-car) package includes library functions for packing and unpacking files into CARs, using the IPFS UnixFs data model. The library includes the same functionality as the ipfs-car command line utility [described above](https://storacha.network/docs/how-tos/work-with-car-files/#ipfs-car). See the `ipfs-car` [README](https://github.com/web3-storage/ipfs-car#api) for API documentation and usage examples. ### `@ipld/car` -The [`@ipld/car`](https://github.com/ipld/js-car) package contains the main JavaScript implementation of the CAR specification and is used by ipfs-car under the hood. If you want to store non-file data using [advanced IPLD formats](https://web3.storage/docs/how-tos/work-with-car-files/#advanced-ipld-formats), you should use @ipld/car directly. +The [`@ipld/car`](https://github.com/ipld/js-car) package contains the main JavaScript implementation of the CAR specification and is used by ipfs-car under the hood. If you want to store non-file data using [advanced IPLD formats](https://storacha.network/docs/how-tos/work-with-car-files/#advanced-ipld-formats), you should use @ipld/car directly. -@ipld/car also provides the CarReader interface used by the web3.storage client's [putCar](https://web3.storage/docs/reference/js-client-library/#store-car-files)[method](https://web3.storage/docs/reference/js-client-library/#store-car-files). +@ipld/car also provides the CarReader interface used by the Storacha client's [putCar](https://storacha.network/docs/reference/js-client-library/#store-car-files)[method](https://storacha.network/docs/reference/js-client-library/#store-car-files). -Here's a simple example of loading a CAR file from a Node.js stream and storing it with web3.storage: +Here's a simple example of loading a CAR file from a Node.js stream and storing it with Storacha: ```js import fs from 'node:fs' diff --git a/src/pages/docs/concepts/content-addressing.md b/src/pages/docs/concepts/content-addressing.md index e24834a..7ca46b5 100644 --- a/src/pages/docs/concepts/content-addressing.md +++ b/src/pages/docs/concepts/content-addressing.md @@ -1,33 +1,33 @@ # Content addressing -web3.storage's decentralized file storage relies on _content addressing_ to find, reference, and retrieve your files on the network. Content addressing is a technique for organizing and locating data in a system in which the key used to locate content is derived from the content itself, rather than its location. While you don't need to understand content addressing to be able to incorporate web3.storage in your apps and services, if you're curious about what's going on under the hood, read on. +Storacha's decentralized file storage relies on _content addressing_ to find, reference, and retrieve your files on the network. Content addressing is a technique for organizing and locating data in a system in which the key used to locate content is derived from the content itself, rather than its location. While you don't need to understand content addressing to be able to incorporate sSoracha in your apps and services, if you're curious about what's going on under the hood, read on. ## The basic problem -Consider what happens when you resolve a link like `web3.storage/docs/concepts/content-addressing`. First, your operating system queries a global shared key-value store, split into many domains — you may know this as the Domain Name System (DNS). The DNS returns an IP address that your network card can use to send HTTP requests over the network, where this site's naming conventions turn the key `/docs/concepts/content-addressing` into a response payload. +Consider what happens when you resolve a link like `storacha.network/docs/concepts/content-addressing`. First, your operating system queries a global shared key-value store, split into many domains — you may know this as the Domain Name System (DNS). The DNS returns an IP address that your network card can use to send HTTP requests over the network, where this site's naming conventions turn the key `/docs/concepts/content-addressing` into a response payload. -The problem is, components of an address like `web3.storage/docs/concepts/content-addressing` are _mutable_, meaning they can change over time. In the context of the web, where _everything_ is mutable and dynamic, this is just the way it's always been. As a result, [link rot](https://en.wikipedia-on-ipfs.org/wiki/Link_rot) is just something we've all learned to live with. +The problem is, components of an address like `storacha.network/docs/concepts/content-addressing` are _mutable_, meaning they can change over time. In the context of the web, where _everything_ is mutable and dynamic, this is just the way it's always been. As a result, [link rot](https://en.wikipedia-on-ipfs.org/wiki/Link_rot) is just something we've all learned to live with. ## CIDs: Location-independent, globally unique keys -However, thanks to content addressing, link rot may become a thing of the past. A content-addressed system such as web3.storage is like our key-value-based DNS, with one significant difference: You no longer get to choose the keys. Instead, the keys are derived directly from the file contents using an algorithm that will always generate the same key for the same content. +However, thanks to content addressing, link rot may become a thing of the past. A content-addressed system such as Storacha is like our key-value-based DNS, with one significant difference: You no longer get to choose the keys. Instead, the keys are derived directly from the file contents using an algorithm that will always generate the same key for the same content. As a result, we no longer need to coordinate among multiple writers to our store by splitting the key space into domains and locations on file systems. There's now one universal domain: the domain of all possible values. If multiple people add the same value, there's no collision in the key space. They just each get the same key back from the put method, with one additional benefit: The availability and performance of retrievals on the network is increased. This gives our keys _location independence_. There's one other important result: Each individual key is a unique signature for the data itself, ensuring _verifiability_ that the key matches the content and the content hasn't been altered. -This type of key is called a _content identifier (CID)_. Once you know the CID of a file on the web3.storage network, you have all you need for the network to locate and return the file back to you. +This type of key is called a _content identifier (CID)_. Once you know the CID of a file on the Storacha network, you have all you need for the network to locate and return the file back to you. -## web3.storage CIDs under the hood +## Storacha CIDs under the hood -web3.storage uses CIDs to make its decentralized file storage work, with help from [IPFS](https://ipfs.io/) for locating files and making sure they're always available. +Storacha uses CIDs to make its decentralized file storage work, with help from [IPFS](https://ipfs.io/) for locating files and making sure they're always available. -Content addressing is the basis of the peer-to-peer hypermedia protocol IPFS (the InterPlanetary File System), which web3.storage uses to locate files. When web3.storage stores your data on IPFS, it can be retrieved from any IPFS node that has a copy of that data. This can make data transfers more efficient and reduce the load on any single node. As each user fetches a piece of data, they keep a local copy around to help other users who might request it later. +Content addressing is the basis of the peer-to-peer hypermedia protocol IPFS (the InterPlanetary File System), which Storacha uses to locate files. When Storacha stores your data on IPFS, it can be retrieved from any IPFS node that has a copy of that data. This can make data transfers more efficient and reduce the load on any single node. As each user fetches a piece of data, they keep a local copy around to help other users who might request it later. -In addition to web3.storage making it easy to get your data onto the content-addressed IPFS network, it also provides long-term persistence for your files using the decentralized Filecoin storage network. The Filecoin network incentivizes participants to provide storage space for files on the network. By combining IPFS and Filecoin storage into one easy-to-use service, web3.storage makes it simple to store, locate, and retrieve your files on the decentralized web. +In addition to Storacha making it easy to get your data onto the content-addressed IPFS network, it also provides long-term persistence for your files using the decentralized Filecoin storage network. The Filecoin network incentivizes participants to provide storage space for files on the network. By combining IPFS and Filecoin storage into one easy-to-use service, Storacha makes it simple to store, locate, and retrieve your files on the decentralized web. -There are two types of CIDs that web3.storage interacts with: +There are two types of CIDs that Storacha interacts with: - Content CIDs: The CIDs used to reference and access uploads in the format generally useful to users (e.g., files, directories). These CIDs are generally prefixed by `bafy…`. This is what the vast majority of IPFS users will be using. -- Shard CIDs: The CID of the serialized shards of data itself that are produced client-side, sent to web3.storage, and stored. These CIDs are generally prefixed by `bag…`. +- Shard CIDs: The CID of the serialized shards of data itself that are produced client-side, sent to Storacha, and stored. These CIDs are generally prefixed by `bag…`. In the vast majority of cases, users should focus on content CIDs, as this is what they'll be using to fetch their content. If you stick with using the recommended client and CLI methods, then you won't really have to ever worry about the shard CIDs. diff --git a/src/pages/docs/concepts/filecoin-storage.md b/src/pages/docs/concepts/filecoin-storage.md index b1fedd7..1317122 100644 --- a/src/pages/docs/concepts/filecoin-storage.md +++ b/src/pages/docs/concepts/filecoin-storage.md @@ -4,8 +4,8 @@ The Filecoin network is a great building block for any decentralized storage sys Read more about Filecoin proofs [here](https://filecoin.io/blog/posts/what-sets-us-apart-filecoin-s-proof-system/). -Because of the open nature of the Filecoin network allowing anyone to participate, it's very inexpensive to store data on the Filecoin network. As a result, web3.storage uses the network today to back up all its data on the decentralized web. In the future, we will launch new products that allow users to take advantage of Filecoin for "colder," disruptively expensive data storage. +Because of the open nature of the Filecoin network allowing anyone to participate, it's very inexpensive to store data on the Filecoin network. As a result, Storacha uses the network today to back up all its data on the decentralized web. In the future, we will launch new products that allow users to take advantage of Filecoin for "colder," disruptively expensive data storage. -The great thing about IPFS is that, regardless of where your data is sitting (on web3.storage's dedicated servers, Filecoin, on your local IPFS node, or anywhere else), you access your data the same way - using the data's content address - and allows you to tune how many copies you have if you'd like, which has tradeoffs in terms of cost, availability, and read performance! +The great thing about IPFS is that, regardless of where your data is sitting (on Storacha's dedicated servers, Filecoin, on your local IPFS node, or anywhere else), you access your data the same way - using the data's content address - and allows you to tune how many copies you have if you'd like, which has tradeoffs in terms of cost, availability, and read performance! -When storing data on Filecoin, you enter storage "deals" that have a finite duration. web3.storage service currently renews deals for you to ensure your data deals never expire. +When storing data on Filecoin, you enter storage "deals" that have a finite duration. Storacha service currently renews deals for you to ensure your data deals never expire. diff --git a/src/pages/docs/concepts/ipfs-gateways.md b/src/pages/docs/concepts/ipfs-gateways.md index bbd38b8..d3987f8 100644 --- a/src/pages/docs/concepts/ipfs-gateways.md +++ b/src/pages/docs/concepts/ipfs-gateways.md @@ -1,6 +1,6 @@ # IPFS HTTP Gateways -web3.storage uses the [InterPlanetary File System (IPFS)](https://ipfs.io/) as a key part of its storage and retrieval infrastructure. +Storacha uses the [InterPlanetary File System (IPFS)](https://ipfs.io/) as a key part of its storage and retrieval infrastructure. The IPFS network is a peer-to-peer network of computers that share resources to efficiently provide content to anyone that requests it. Computers that join the IPFS network supply blocks of data using a hash-based Content Identifiers (CIDs). diff --git a/src/pages/docs/concepts/podsi.mdx b/src/pages/docs/concepts/podsi.mdx index 6b4ee0e..4e30d26 100644 --- a/src/pages/docs/concepts/podsi.mdx +++ b/src/pages/docs/concepts/podsi.mdx @@ -2,17 +2,17 @@ import { Callout, Steps } from 'nextra/components' # Proof of Data Segment Inclusion (PoDSI) -Data uploaded to web3.storage is aggregated together with data from other users of the service. When an aggregate is big enough, it is stored with multiple Filecoin Storage Providers. +Data uploaded to Storacha is aggregated together with data from other users of the service. When an aggregate is big enough, it is stored with multiple Filecoin Storage Providers. Storage Providers have minimum size requirements for data storage. Therefore it is necessary to aggregate data to satisfy the requirements. The minimum is typically between 16 and 32GB. -The web3.storage service uses **Proof of Data Segment Inclusion** (PoDSI), which allows clients to verify the correct aggregation of their data and prove this fact to third parties. +The Storacha service uses **Proof of Data Segment Inclusion** (PoDSI), which allows clients to verify the correct aggregation of their data and prove this fact to third parties. ## Shard CIDs -Data uploaded to web3.storage is packed up and sent as CAR files. We call these _shards_, and each one is referenced by it's shard CID. +Data uploaded to Storacha is packed up and sent as CAR files. We call these _shards_, and each one is referenced by it's shard CID. ```sh # example CAR shard CID @@ -29,7 +29,7 @@ The IPLD codec for a CAR shard CID is `0x0202`. You can [inspect this CID on cid Piece CIDs are the primary means of referencing data stored in a sector of a Filecoin Storage Provider. Each piece CID is loosely equivalent to a corresponding [shard CID](#shard-cids). -The piece CIDs used in web3.storage are v2 piece CIDs since these also encode tree _height_ information. On chain and in various chain explorers online you may see v1 piece CIDs displayed. You can convert from v2 to v1 but not v1 to v2, unless you also know the tree height. +The piece CIDs used in Storacha are v2 piece CIDs since these also encode tree _height_ information. On chain and in various chain explorers online you may see v1 piece CIDs displayed. You can convert from v2 to v1 but not v1 to v2, unless you also know the tree height. [FRC-0069 documentation for Piece CID v2](https://github.com/filecoin-project/FIPs/blob/master/FRCs/frc-0069.md). @@ -42,7 +42,7 @@ The IPLD codec for the above multihash is `0x1011` (fr32-sha2-256-trunc254-padde ## Proof of Data Segment Inclusion (PoDSI) -PoDSI enables clients using data aggregation services like web3.storage to verify the correct aggregation of their data and allow proving of this fact to third parties. +PoDSI enables clients using data aggregation services like Storacha to verify the correct aggregation of their data and allow proving of this fact to third parties. Put simply, it is a proof that a smaller piece (a segment) has been included in a larger piece (an aggregate). @@ -79,7 +79,7 @@ A data aggregation proof is a [PoDSI](#proof-of-data-segment-inclusion-podsi), _ ## Verifiable Aggregation Pipeline -The web3.storage aggregation pipeline is fully verifiable thanks to [UCAN](/docs/concepts/ucans-and-web3storage)s. Your piece can be tracked through the pipeline via signed UCAN receipts. +The Storacha aggregation pipeline is fully verifiable thanks to [UCAN](/docs/concepts/ucans-and-web3storage)s. Your piece can be tracked through the pipeline via signed UCAN receipts. There are 4 roles in the aggregation pipeline: @@ -93,7 +93,7 @@ Roughly speaking, a piece progresses through the pipeline via the following stag ### `filecoin/offer` -The client submits a piece to the _storefront_ (web3.storage) for aggregation and storage in Filecoin storage providers. The receipt for this invocation contains two links for async tasks: +The client submits a piece to the _storefront_ (storacha) for aggregation and storage in Filecoin storage providers. The receipt for this invocation contains two links for async tasks: 1. `filecoin/submit` - allows the client to continue following the receipt chain through the aggregation pipeline. It is executed after the _storefront_ has verified the piece CID corresponds to the shard CID. 1. `filecoin/accept` - a "short cut" to the end of the pipeline, where the data aggregation proof will eventually become available. It is executed when the _dealer_ has successfully stored an aggregate containing the submitted piece in one or more Filecoin Storage Providers. diff --git a/src/pages/docs/concepts/ucan.md b/src/pages/docs/concepts/ucan.md index a4ce5fc..d238765 100644 --- a/src/pages/docs/concepts/ucan.md +++ b/src/pages/docs/concepts/ucan.md @@ -1,6 +1,6 @@ # UCAN: User controlled authorization networks -The w3up platform by web3.storage is built on a technology called UCAN, a system which takes a different approach to user identity and authorization than you may be used to from building or interacting with "web 2.0" services. Read on to learn about what makes UCAN special. +The w3up platform by Storacha is built on a technology called UCAN, a system which takes a different approach to user identity and authorization than you may be used to from building or interacting with "web 2.0" services. Read on to learn about what makes UCAN special. UCAN stands for User Controlled Authorization Networks, and it's fundamentally about changing the relationship between users and service providers in a way that empowers the end-user. @@ -58,25 +58,25 @@ In our [Intro to UCAN article](./index.md), we gave a high-level overview of the When applications use the w3ui components, or developers run the `w3` CLI, they need access to a "space," which is a unique ID that groups uploads together. Once a space has been registered with the w3up service, it can be used to upload files and other data. -If you're uploading files from your laptop using [the `w3` command line tool](../../getting-started/w3cli.md), you can just create a space on the laptop and register it with the w3up service using the `w3 space register` command. The service will issue you a UCAN token that grants your client's "agent" some capabilities; in this case, you get the ability to upload data to web3.storage, list your uploads, unlink uploads from your account, etc. +If you're uploading files from your laptop using [the `w3` command line tool](../../getting-started/w3cli.md), you can just create a space on the laptop and register it with the w3up service using the `w3 space register` command. The service will issue you a UCAN token that grants your client's "agent" some capabilities; in this case, you get the ability to upload data to Storacha, list your uploads, unlink uploads from your account, etc. Each client that you use to access w3up will have an "agent" associated with it. Agents are what we call the component that manages your local private keys and signs UCAN requests to the w3up service. When you create a space and register it, the agent you use to register the space is automatically issued a UCAN delegation that grants the agent the ability to upload to the space, as well as other "space related" capabilities like listing uploads. Because your laptop has access to the private key for your agent, and your agent has access to the space, there's no need to delegate anything. The `w3` tool will just sign a UCAN request token with your agent's private key and will include all the required proofs that you have the right permissions. -Another example is a fully decentralized app with a web frontend that interacts with a smart contract "backend." Let's say you're building a decentralized image sharing application, where users can get rewarded for sharing funny memes. You'd like your app's users to be able to upload images to web3.storage, but you don't want to coordinate their access or handle billing on their behalf. +Another example is a fully decentralized app with a web frontend that interacts with a smart contract "backend." Let's say you're building a decentralized image sharing application, where users can get rewarded for sharing funny memes. You'd like your app's users to be able to upload images to Storacha, but you don't want to coordinate their access or handle billing on their behalf. -In that case, you can use the [w3ui keyring component](https://beta.ui.web3.storage/keyring) to help your users create their own spaces and register them with w3up. There's no need for delegation in this case, because each user has their own registered account with web.storage. +In that case, you can use the [w3ui keyring component](https://beta.ui.storacha/keyring) to help your users create their own spaces and register them with w3up. There's no need for delegation in this case, because each user has their own registered account with web.storage. ## App owned accounts - transparent to the user -Now let's see where web3.storage delegation can improve the experience for end users of traditional apps. By delegating to a user's session the capability to upload to your app's w3up spaces, you can add uploads to an app without impacting your infrastructure, completely invisibly to users. +Now let's see where Storacha delegation can improve the experience for end users of traditional apps. By delegating to a user's session the capability to upload to your app's w3up spaces, you can add uploads to an app without impacting your infrastructure, completely invisibly to users. -Let's say that you run a recipe sharing app written on traditional web2 technologies. You have a sizeable user-base, and you want to add recipe photo uploads without impacting your existing infrastructure. With UCAN delegation, users can upload directly to your web3.storage space, with no visible impact on the user experience. +Let's say that you run a recipe sharing app written on traditional web2 technologies. You have a sizeable user-base, and you want to add recipe photo uploads without impacting your existing infrastructure. With UCAN delegation, users can upload directly to your Storacha space, with no visible impact on the user experience. -To do this, you can delegate access to your own web3.storage space, instead of having each user create their own space. +To do this, you can delegate access to your own Storacha space, instead of having each user create their own space. -On the client side, each user will still create an agent with a public/private keypair, but instead of using the agent to register with web3.storage, they can send the agent's public ID to your app's web API or cloud function. That service will issue a UCAN that grants some permissions to the user's agent, without needing to coordinate anything between your app's backend and the web3.storage service. In that way, storage access is attached to your application's session. +On the client side, each user will still create an agent with a public/private keypair, but instead of using the agent to register with Storacha, they can send the agent's public ID to your app's web API or cloud function. That service will issue a UCAN that grants some permissions to the user's agent, without needing to coordinate anything between your app's backend and the Storacha service. In that way, storage access is attached to your application's session. When a new user signs into your web app, the frontend can use [`w3up-client`](../../getting-started/w3up-client.md), which will automatically create an agent keypair on first run. Instead of using the client to create and register spaces belonging to the user, the frontend can send the agent's public ID to your backend service instead. @@ -147,7 +147,7 @@ async function getDIDFromRequest (request) { } ``` -When the frontend recieves the delegation from your service, they can call [`addProof`][reference-client#addproof] on their `w3up-client` instance and pass in the bytes of the delegation object. They will also need to call `client.setCurrentSpace(spaceDID)`, passing in the DID for the space that you delegated access to. Once that's done, they should be able to use the `uploadFile` and `uploadDirectory` client methods to send data to your web3.storage space. +When the frontend recieves the delegation from your service, they can call [`addProof`][reference-client#addproof] on their `w3up-client` instance and pass in the bytes of the delegation object. They will also need to call `client.setCurrentSpace(spaceDID)`, passing in the DID for the space that you delegated access to. Once that's done, they should be able to use the `uploadFile` and `uploadDirectory` client methods to send data to your Storacha space. Note that in our example above, we granted a limited set of capabilities, so that our user can upload but not access any other functionality related to the space. If you want to delegate all permissions, use the `'*'` ability in your delegation, and use the client's [`addSpace` method][reference-client#addspace] instead of `addProof`. @@ -155,7 +155,7 @@ Note that in our example above, we granted a limited set of capabilities, so tha You can also use delegation to share access with other services, without requiring an explicit agreement between each service provider. -For example, you or your users could delegate access to an image resizing app that will create thumbnails of each uploaded image and write them back to web3.storage. While you could do this without delegation by having the image app use its own web3.storage account, the uploads would be attached to the space registered to the app. By using delegation, you'll be able to see the CIDs for the thumbnails in the upload listing for the user's account instead, and the resizing app doesn't need to have any kind of business relationship with web3.storage to use the service. +For example, you or your users could delegate access to an image resizing app that will create thumbnails of each uploaded image and write them back to Storacha. While you could do this without delegation by having the image app use its own Storacha account, the uploads would be attached to the space registered to the app. By using delegation, you'll be able to see the CIDs for the thumbnails in the upload listing for the user's account instead, and the resizing app doesn't need to have any kind of business relationship with Storacha to use the service. ### Link devices through delegation @@ -289,7 +289,7 @@ Note that the `w3 delegation create` command we used in step 5 delegates the `'* UCAN delegation is a powerful tool for managing access to your w3up resources. Hopefully this post has given you some ideas about how delegation can help you build out new experiences using w3up. -Thanks for following along, and feel free to [get in touch](https://web3.storage/docs/community/help-and-support/) if you have any questions! +Thanks for following along, and feel free to [get in touch](https://storacha.network/docs/community/help-and-support/) if you have any questions! [reference-client#createdelegation]: ../../api/w3up-client/classes/client.Client.md#createdelegation diff --git a/src/pages/docs/concepts/ucans-and-web3storage.md b/src/pages/docs/concepts/ucans-and-web3storage.md index 174ddef..2692f47 100644 --- a/src/pages/docs/concepts/ucans-and-web3storage.md +++ b/src/pages/docs/concepts/ucans-and-web3storage.md @@ -1,4 +1,4 @@ -# UCANs and web3.storage +# UCANs and storacha For authorization, w3up services use [ucanto](https://github.com/web3-storage/ucanto), a Remote Procedure Call (RPC) framework built around [UCAN](https://ucan.xyz/), or User Controlled Authorization Networks. UCANs are a powerful capability-based authorization system that allows fine-grained sharing of permissions through a process called _delegation_ on top of [public key cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography). @@ -6,17 +6,17 @@ You can think about UCAN replacing bearer tokens in traditional APIs for authori ## How w3up and w3up-client use UCANs -Our client and CLI use ucanto to take care of the details of UCANs for you, but a few of the underlying terms and concepts may "bubble up" to the surface of the API, so we'll cover the basics. We'll also go over some terms that are specific to web3.storage that you might not have encountered elsewhere. +Our client and CLI use ucanto to take care of the details of UCANs for you, but a few of the underlying terms and concepts may "bubble up" to the surface of the API, so we'll cover the basics. We'll also go over some terms that are specific to Storacha that you might not have encountered elsewhere. UCAN-based APIs are centered around _capabilities_, which are comprised of an _ability_ and a _resource_. Together, the ability and resource determine what action a client can perform and what objects in the system can be acted upon. When invoking a service method, a client will present a UCAN token that includes an ability and resource, along with _proofs_ that verify that they should be allowed to exercise the capability. The proof might be signed directly by the capability owner, or have a chain of signatures (_delegations_) where the actor invoking the capability has been verifiably delegated permission to do so. ### Space -When you upload data to w3up, your uploads are linked to a unique _Space_ that acts as a "namespace" for the data you upload. Each Space corresponds to a _DID_, or [Decentralized Identity Document](https://www.w3.org/TR/did-core/). In web3.storage's implementation of w3up, these Space DIDs generally use the key DID method, of the form did:key:publicKey with a corresponding private signing key. +When you upload data to w3up, your uploads are linked to a unique _Space_ that acts as a "namespace" for the data you upload. Each Space corresponds to a _DID_, or [Decentralized Identity Document](https://www.w3.org/TR/did-core/). In Storacha's implementation of w3up, these Space DIDs generally use the key DID method, of the form did:key:publicKey with a corresponding private signing key. -When creating a Space, it generates this private key and did:key for you locally. To use web3.storage, you then register a Space by associating it with your email address. From there, when invoking storage capabilities with web3.storage, the Space did:key is the "resource" portion of the capability, while the ability is an action like space/blob/add or space/blob/remove. (A Space registered with web3.storage is imperfectly analogous to an "account" with web3.storage.) +When creating a Space, it generates this private key and did:key for you locally. To use Storacha, you then register a Space by associating it with your email address. From there, when invoking storage capabilities with Storacha, the Space did:key is the "resource" portion of the capability, while the ability is an action like space/blob/add or space/blob/remove. (A Space registered with Storacha is imperfectly analogous to an "account" with Storacha.) -Under the hood in the email registration process, your Space delegates the capabilities needed to use w3up to your email address, and this delegation is stored by web3.storage. If you need access to your Space in the future from any device, web3.storage allows you to reclaim those capabilities the same way you would reset a password in other services - using an email verification process. This means you don't need to store or manage Space private keys to use w3up - just create a new space, register it with w3up and use it from as many devices as you like. More on this "sign in" process is detailed in the next section on Agents. +Under the hood in the email registration process, your Space delegates the capabilities needed to use w3up to your email address, and this delegation is stored by Storacha. If you need access to your Space in the future from any device, Storacha allows you to reclaim those capabilities the same way you would reset a password in other services - using an email verification process. This means you don't need to store or manage Space private keys to use w3up - just create a new space, register it with w3up and use it from as many devices as you like. More on this "sign in" process is detailed in the next section on Agents. ### Agent diff --git a/src/pages/docs/concepts/upload-vs-store.md b/src/pages/docs/concepts/upload-vs-store.md index e8762f0..a46d968 100644 --- a/src/pages/docs/concepts/upload-vs-store.md +++ b/src/pages/docs/concepts/upload-vs-store.md @@ -1,9 +1,9 @@ -# Upload vs. Store capabilities in web3.storage +# Upload vs. Store capabilities in Storacha -There are three types of content identifiers (CIDs) that web3.storage interacts with: +There are three types of content identifiers (CIDs) that Storacha interacts with: 1. **Content CIDs**: The CIDs used to reference and access uploads in the format generally useful to users (e.g., files, directories). These CIDs are generally prefixed by `bafy…`. -2. **Shard CIDs**: The CID of the serialized shards of data itself that are produced client-side, sent to web3.storage, and stored. These CIDs are generally prefixed by `bag…`. +2. **Shard CIDs**: The CID of the serialized shards of data itself that are produced client-side, sent to Storacha, and stored. These CIDs are generally prefixed by `bag…`. 3. **Piece CIDs**: The primary means of referencing data stored in a sector of a Filecoin Storage Provider. You can think of them as another way to reference a shard. These CIDs are generally prefixed by `bafk…`. One example of where you might see all three is uploading a large file with the CLI: @@ -35,23 +35,23 @@ The CLI sharded the ~1GB upload into 8 shards, each with a `bag…`-prefixed CID In the vast majority of cases, users should focus on content CIDs, as this is what they'll be using to fetch their content. If you stick with using the recommended client and CLI methods, then you won't really have to ever worry about the shard CIDs. -However, if you're interested in learning more about how web3.storage uses all three, read on! +However, if you're interested in learning more about how Storacha uses all three, read on! ## Upload vs. Store -There are two similar-sounding, complementary, but separate concepts in web3.storage: Upload and Store. The place you most readily see this is in the lower-level client methods like `client.capability.upload.*` and `client.capability.store.*`, and CLI methods like `w3 can upload *`, and `w3 can store *`. +There are two similar-sounding, complementary, but separate concepts in Storacha: Upload and Store. The place you most readily see this is in the lower-level client methods like `client.capability.upload.*` and `client.capability.store.*`, and CLI methods like `w3 can upload *`, and `w3 can store *`. The main difference is that upload methods interact with content CIDs and store methods interact with shard CIDs. However, both are needed to make your uploads available to the IPFS network! Let's break it down. In the CLI example above where we called `w3 up file`, we saw that both shard CIDs and a content CID were returned. That's because `w3 up` calls both `store` and `upload` were called under the hood (but abstracts the complexity for any user that doesn't care about it). -The CLI and client first take the upload and converts it into an DAG (directed acyclic graph). This is what IPFS uses to generate the content CID - each node in the graph has its own CID, with the graph's leafs containing the upload's data, and the root node of the graph the content CID of the entire graph. However, to send the data to web3.storage, the content has to be in a different form. web3.storage achieves this by converting the graph into a set of CAR file shards. +The CLI and client first take the upload and converts it into an DAG (directed acyclic graph). This is what IPFS uses to generate the content CID - each node in the graph has its own CID, with the graph's leafs containing the upload's data, and the root node of the graph the content CID of the entire graph. However, to send the data to Storacha, the content has to be in a different form. Storacha achieves this by converting the graph into a set of CAR file shards. -Each CAR shard has a CID associated with the data itself (i.e., as it sits on disk serialized, with a header for instructions on how the blocks within the serialized data should be arranged, etc.). The CLI and client send each of these shards one-by-one to web3.storage by invoking the `space/blob/add` UCAN capability under the hood (e.g., `w3 can blob add`)! +Each CAR shard has a CID associated with the data itself (i.e., as it sits on disk serialized, with a header for instructions on how the blocks within the serialized data should be arranged, etc.). The CLI and client send each of these shards one-by-one to Storacha by invoking the `space/blob/add` UCAN capability under the hood (e.g., `w3 can blob add`)! -However, from web3.storage's perspective, it doesn't necessarily know whether the set of CAR shards it was sent from the series of `space/blob/add`s corresponds to a single content CID that the user cares about, multiple content CIDs, or none at all (e.g., the CAR files sent represent an incomplete graph). As a result, `upload/add` allows the user to explicitly register a content CID with a set of shard CIDs. This is primarily done for the user's sake - it makes it easier to track which content CIDs (what they're using to fetch data from the IPFS network) correspond to which shard CIDs (what is physically being stored with web3.storage). +However, from Storacha's perspective, it doesn't necessarily know whether the set of CAR shards it was sent from the series of `space/blob/add`s corresponds to a single content CID that the user cares about, multiple content CIDs, or none at all (e.g., the CAR files sent represent an incomplete graph). As a result, `upload/add` allows the user to explicitly register a content CID with a set of shard CIDs. This is primarily done for the user's sake - it makes it easier to track which content CIDs (what they're using to fetch data from the IPFS network) correspond to which shard CIDs (what is physically being stored with Storacha). -In cases where the user is uploading a whole file or directory like in the example above, it's safe to know that the series of CAR shards uploaded by the user correspond to the file's content CID that it cares about. That's why the higher-level `w3 up` method is appropriate to use, and should represent the vast majority of upload use cases by web3.storage users. +In cases where the user is uploading a whole file or directory like in the example above, it's safe to know that the series of CAR shards uploaded by the user correspond to the file's content CID that it cares about. That's why the higher-level `w3 up` method is appropriate to use, and should represent the vast majority of upload use cases by Storacha users. ## When should I care about Store and shard CIDs? @@ -69,7 +69,7 @@ This results in only a single copy of each file being stored, but you being able ### Removing data from an account -web3.storage tracks usage for payment (i.e., how much storage is utilized by a user) using the volume of data associated with shard CIDs. This should make sense after learning about the difference between `store` and `upload` - web3.storage is storing the CAR shards themselves, and `upload`s are more users tracking. +Storacha tracks usage for payment (i.e., how much storage is utilized by a user) using the volume of data associated with shard CIDs. This should make sense after learning about the difference between `store` and `upload` - Storacha is storing the CAR shards themselves, and `upload`s are more users tracking. Fortunately, this shouldn't make things any more complicated - we go into more detail below, but in general, when you remove a content CID from your account, you'll want to remove the shard CIDs as well (e.g., in the client calling `client.remove(contentCID, { shards: true })`). diff --git a/src/pages/docs/faq.md b/src/pages/docs/faq.md index 75ab530..0583e41 100644 --- a/src/pages/docs/faq.md +++ b/src/pages/docs/faq.md @@ -1,25 +1,25 @@ # Frequently Asked Questions -## What advantages does web3.storage have over traditional hosted storage services? +## What advantages does Storacha have over traditional hosted storage services? -Because web3.storage uses decentralized data and identity protocols like IPFS and UCAN, data and identity are referenced in an open way. Data is referenced using IPFS content identifiers that are unique to the data, making your data completely portable - accessible from anywhere broadcasting data to the IPFS network, whether on a local or peer device, or uploaded to web3.storage itself. Data is backed up on Filecoin, which gives cryptographic proof that your data is physically being stored without needing to trust web3.storage. +Because Storacha uses decentralized data and identity protocols like IPFS and UCAN, data and identity are referenced in an open way. Data is referenced using IPFS content identifiers that are unique to the data, making your data completely portable - accessible from anywhere broadcasting data to the IPFS network, whether on a local or peer device, or uploaded to Storacha itself. Data is backed up on Filecoin, which gives cryptographic proof that your data is physically being stored without needing to trust Storacha. -Authentication is associated with user decentralized identifiers (DIDs) that sign UCAN tokens that can be cryptographically verified by the web3.storage service, meaning that your identity is not determined by a central authentication server. And because any storage solution can utilize the same UCAN and IPFS content IDs, there is no lock-in to web3.storage’s service. +Authentication is associated with user decentralized identifiers (DIDs) that sign UCAN tokens that can be cryptographically verified by the Storacha service, meaning that your identity is not determined by a central authentication server. And because any storage solution can utilize the same UCAN and IPFS content IDs, there is no lock-in to Storacha’s service. -## What advantages does web3.storage have over other IPFS hosted services? +## What advantages does Storacha have over other IPFS hosted services? -web3.storage runs on a serverless implementation of IPFS that is optimized for scale and cost. -We wrote it as the solution to address increasing adoption of web3.storage, which previously used kubo and IPFS Cluster. As a result, web3.storage is designed to give strong performance and reliability regardless of how much data is being stored on it, meaning that you can rely on it as you and web3.storage grow. And all data is backed up in Filecoin storage deals, which gives cryptographic proof that your data is physically being stored without needing to trust web3.storage. +Storacha runs on a serverless implementation of IPFS that is optimized for scale and cost. +We wrote it as the solution to address increasing adoption of Storacha, which previously used kubo and IPFS Cluster. As a result, Storacha is designed to give strong performance and reliability regardless of how much data is being stored on it, meaning that you can rely on it as you and Storacha grow. And all data is backed up in Filecoin storage deals, which gives cryptographic proof that your data is physically being stored without needing to trust Storacha. -## How do I store data on web3.storage that is already available over the IPFS network without having to download and reupload it myself? +## How do I store data on Storacha that is already available over the IPFS network without having to download and reupload it myself? To keep costs low, we no longer offer an implementation of the Pinning Service API. But fear not, you can just download a copy of your content in CAR file form (e.g., access your data via `https://{cid}.ipfs.dweb.link/path?format=car`) and upload that directly using w3up. We’re working on a new product to make it as easy as possible to do this! -## How can I delete items from web3.storage? +## How can I delete items from Storacha? You can delete files listed in your account. Simply log-in to your account and use the file manager on the files page, or use the client’s remove method. -However, once a file is uploaded to web3.storage, there cannot be a guarantee that all copies of the file are gone from the IPFS network. As soon as a file is uploaded, other IPFS nodes can access and store a copy of the data. The data only becomes unavailable when the last IPFS node has stopped pinning the file, and all copies are garbage collected. As a consequence you should only upload to web3.storage files that you know can be shared with anyone forever, or are securely encrypted. +However, once a file is uploaded to Storacha, there cannot be a guarantee that all copies of the file are gone from the IPFS network. As soon as a file is uploaded, other IPFS nodes can access and store a copy of the data. The data only becomes unavailable when the last IPFS node has stopped pinning the file, and all copies are garbage collected. As a consequence you should only upload to Storacha files that you know can be shared with anyone forever, or are securely encrypted. ## Are there client libraries other than Javascript? diff --git a/src/pages/docs/glossary.yml b/src/pages/docs/glossary.yml index b775f25..6abd733 100644 --- a/src/pages/docs/glossary.yml +++ b/src/pages/docs/glossary.yml @@ -20,12 +20,12 @@ - id: bitswap definition: A peer-to-peer protocol used by IPFS and Filecoin to distribute blocks of data throughout the network. details: | - While the w3up APIs do not use Bitswap directly, once data is stored with web3.storage it is made available via Bitswap to the larger IPFS network. + While the w3up APIs do not use Bitswap directly, once data is stored with Storacha it is made available via Bitswap to the larger IPFS network. - id: block definition: A chunk of binary data that can be identified by CID. details: | - Data stored with web3.storage is encoded into blocks, with large files consisting of several blocks linked together. + Data stored with Storacha is encoded into blocks, with large files consisting of several blocks linked together. Blocks can be uniquely identified by CID (Content Identifier), and are often bundled into Content Archives (CARs) for transport and storage. @@ -75,7 +75,7 @@ The DHT does not contain the full content - instead a small "provider record" contains addresses of peers who will serve the content on request (e.g. via Bitswap). - Content stored with web3.storage is discoverable via the public IPFS DHT. + Content stored with Storacha is discoverable via the public IPFS DHT. - id: elastic-ipfs name: Elastic IPFS @@ -96,7 +96,7 @@ You can fetch IPFS content from a gateway by creating a gateway URL from the CID of your content, - To use the web3.storage gateway at `w3s.link`, make a URL like this, replacing `${cid}` with the CID you want to link to: + To use the Storacha gateway at `w3s.link`, make a URL like this, replacing `${cid}` with the CID you want to link to: ``` https://${cid}.ipfs.w3s.link @@ -109,7 +109,7 @@ IPFS is a system for organizing, locating, and transmitting data using cryptographic hashes to identify each piece of content. There are many IPFS implementations, which work together to form a public network (as well as specialized private networks). - web3.storage makes all uploaded content available to the IPFS network + Storacha makes all uploaded content available to the IPFS network via Bitswap, as well as via HTTP through gateways. - id: ipld @@ -139,7 +139,7 @@ name: PoDSI definition: Proof of Data Segment Inclusion. details: | - PoDSI enables clients using data aggregation services like web3.storage to + PoDSI enables clients using data aggregation services like Storacha to verify the correct aggregation of their data and allow proving of this fact to third parties. @@ -185,9 +185,9 @@ - id: w3up name: w3up - definition: The name of web3.storage's UCAN-based storage platform. + definition: The name of Storacha's UCAN-based storage platform. details: | - When web3.storage first launched, it offered a traditional "RESTful" / "JSON over HTTP" API, + When Storacha first launched, it offered a traditional "RESTful" / "JSON over HTTP" API, aimed at getting traditional web developers tapped into the potential of decentralized, content addressed storage. diff --git a/src/pages/docs/go-w3up.mdx b/src/pages/docs/go-w3up.mdx index 08b49dd..d7f49e7 100644 --- a/src/pages/docs/go-w3up.mdx +++ b/src/pages/docs/go-w3up.mdx @@ -7,7 +7,7 @@ import { Steps } from 'nextra/components' The Go client is under heavily development and is not as fully featured as the [JS client](/docs/w3up-client). -You can easily integrate web3.storage into your Go apps using `go-w3up`, our Go client for the w3up platform. +You can easily integrate Storacha into your Go apps using `go-w3up`, our Go client for the w3up platform. In this guide, we'll walk through the following steps: @@ -59,7 +59,7 @@ MgCb+bRGl02JqlWMPUxCyntxlYj0T/zLtR2tn8LFvw6+Yke0BKAP/OUu2tXpd+tniEoOzB3pxqxHZpRh ## Obtain proofs -Proofs are delegations to your DID enabling it to perform tasks. Currently the best way to obtain proofs that will allow you to interact with the web3.storage API is to use the w3up JS CLI: +Proofs are delegations to your DID enabling it to perform tasks. Currently the best way to obtain proofs that will allow you to interact with the Storacha API is to use the w3up JS CLI: ### Install w3 CLI @@ -91,7 +91,7 @@ w3 delegation create -c 'store/*' -c 'upload/*' [DID] -o proof.ucan ## Load private key and proofs -To interact with the web3.storage API you need your private key to sign UCAN invocations and a proof that your key has been delegated capabilities to perform tasks: +To interact with the Storacha API you need your private key to sign UCAN invocations and a proof that your key has been delegated capabilities to perform tasks: ```go package main @@ -118,7 +118,7 @@ proof, _ := delegation.ExtractProof(b) ## Upload a CAR -Once you have loaded your space DID, your private key and your delegation proofs, you can upload a CAR to web3.storage. +Once you have loaded your space DID, your private key and your delegation proofs, you can upload a CAR to Storacha. ```go package main diff --git a/src/pages/docs/how-to/ci.mdx b/src/pages/docs/how-to/ci.mdx index 68ade5d..fdcd154 100644 --- a/src/pages/docs/how-to/ci.mdx +++ b/src/pages/docs/how-to/ci.mdx @@ -2,7 +2,7 @@ import { Callout } from 'nextra/components' # How to upload from CI -> Publish files to IPFS and Filecoin via web3.storage from a Continuous Integration server. +> Publish files to IPFS and Filecoin via Storacha from a Continuous Integration server. Using `w3cli` locally, the steps are @@ -58,13 +58,13 @@ The rest of this document explains the process in more detail. ## Create a space -On your local machine with [w3cli][] installed and logged in (see: https://web3.storage/docs/quickstart/) run +On your local machine with [w3cli][] installed and logged in (see: https://storacha.network/docs/quickstart/) run ```shell $ w3 space create ``` -and follow the instructions. (See: https://web3.storage/docs/how-to/create-space/#using-the-cli if you get stuck.) +and follow the instructions. (See: https://storacha.network/docs/how-to/create-space/#using-the-cli if you get stuck.) If you want to use an existing space, make sure it is set as your current space using `w3 space ls` and `w3 space use` @@ -82,7 +82,7 @@ $ w3 key create --json } ``` -Keep the `key` safe. It will be used by CI to sign requests to web3.storage. +Keep the `key` safe. It will be used by CI to sign requests to Storacha. The `did` from the command above is the public decentalised identifier for that private `key`. @@ -174,7 +174,7 @@ with: - run: echo ${{ steps.w3up.outputs.url }} ``` -It uploads `path_to_add` to web3.storage. +It uploads `path_to_add` to Storacha. It outputs the root CID as `cid` and IPFS Gateway URL as `url` for subsequent steps in your workflow to use. diff --git a/src/pages/docs/how-to/create-account.md b/src/pages/docs/how-to/create-account.md index f1b5128..e87e81a 100644 --- a/src/pages/docs/how-to/create-account.md +++ b/src/pages/docs/how-to/create-account.md @@ -2,7 +2,7 @@ In this how-to guide, you'll learn how to to create a w3up account. -Anyone can use [console.web3.storage](https://console.web3.storage) to create an account and manage their storage using a web browser. Developers can use the `w3cli` command line interface or the `w3up-client` Javascript library. We recommend that developers get familiar with the `w3cli` since it's a powerful tool for many things you might want to do. +Anyone can use [console.storacha.network](https://console.storacha.network) to create an account and manage their storage using a web browser. Developers can use the `w3cli` command line interface or the `w3up-client` Javascript library. We recommend that developers get familiar with the `w3cli` since it's a powerful tool for many things you might want to do. ## Using the CLI @@ -13,11 +13,11 @@ The easiest way to create an account is by using `w3cli`. 3. Once you click on the validation link, you'll be taken to a webpage where you can enter your payment information and select a plan (like our Free tier). 4. Now you have created an account. -## Using console.web3.storage +## Using console.Storacha -1. Visit [console.web3.storage](https://console.web3.storage). +1. Visit [console.storacha.network](https://console.storacha.network). 2. If you don't have an account, the website will ask you for your email address. Enter your email address and submit the form. -3. Check your email for a message from web3.storage including a link to confirm your intention to authenticate using the email you provided. +3. Check your email for a message from Storacha including a link to confirm your intention to authenticate using the email you provided. ## Using the JS client diff --git a/src/pages/docs/how-to/create-space.mdx b/src/pages/docs/how-to/create-space.mdx index aec251b..73ee177 100644 --- a/src/pages/docs/how-to/create-space.mdx +++ b/src/pages/docs/how-to/create-space.mdx @@ -2,9 +2,9 @@ import { Callout } from 'nextra/components' # How to create a space -In this how-to guide, you'll learn how to create a web3.storage Space to organize stored data. For an overview of the various ways web3.storage can be integrated with your application, check out [Architecture Options](/docs/concepts-architecture-options/). +In this how-to guide, you'll learn how to create a Storacha Space to organize stored data. For an overview of the various ways Storacha can be integrated with your application, check out [Architecture Options](/docs/concepts-architecture-options/). -A Space acts as a namespace for your uploads. It is created locally, offline, and associated with a cryptographic key pair (identified by the [`did:key`](https://w3c-ccg.github.io/did-method-key/) of the public key). You can register this Space with your [web3.storage account](/docs/how-to/create-account/) to take responsibility for the uploads in the space. Once you do this, you don't need to worry about keeping track of the Space's private key, because your web3.storage account has been authorized to use the Space. +A Space acts as a namespace for your uploads. It is created locally, offline, and associated with a cryptographic key pair (identified by the [`did:key`](https://w3c-ccg.github.io/did-method-key/) of the public key). You can register this Space with your [storacha account](/docs/how-to/create-account/) to take responsibility for the uploads in the space. Once you do this, you don't need to worry about keeping track of the Space's private key, because your Storacha account has been authorized to use the Space. ## Using the CLI @@ -22,9 +22,9 @@ The easiest way to create and register a Space is by using the CLI. - even if you don't need this level of recovery, you will need to store this phrase and be able to repeat it in the next step - type the recovery phrase so `w3cli` knows you have backed it up, then press the enter key -## Using console.web3.storage +## Using console.storacha.network -Separately, you can visit [console.web3.storage](https://console.web3.storage/), sign up with your email and select a plan, and create a space using the UI, but we recommend that developers get familiar with the CLI since it's a powerful tool for many things you might want to do. +Separately, you can visit [console.storacha](https://console.storacha.network/), sign up with your email and select a plan, and create a space using the UI, but we recommend that developers get familiar with the CLI since it's a powerful tool for many things you might want to do. The Space you create can be used to [upload](/docs/how-to/upload/) data using the CLI, the w3up client, or when you log into the web console. diff --git a/src/pages/docs/how-to/filecoin-info.mdx b/src/pages/docs/how-to/filecoin-info.mdx index 76c9ce8..fa227c5 100644 --- a/src/pages/docs/how-to/filecoin-info.mdx +++ b/src/pages/docs/how-to/filecoin-info.mdx @@ -2,7 +2,7 @@ import { Callout } from 'nextra/components' # Get Filecoin information for a Piece -To retrieve a [Data Aggregation Proof](/docs/concepts/podsi#data-aggregation-proof) (including [PoDSI](/docs/concepts/podsi)) you can issue a `filecoin/info` invocation to the web3.storage service. +To retrieve a [Data Aggregation Proof](/docs/concepts/podsi#data-aggregation-proof) (including [PoDSI](/docs/concepts/podsi)) you can issue a `filecoin/info` invocation to the Storacha service. ## Using the JS client diff --git a/src/pages/docs/how-to/http-bridge.mdx b/src/pages/docs/how-to/http-bridge.mdx index 84b7733..952f3bf 100644 --- a/src/pages/docs/how-to/http-bridge.mdx +++ b/src/pages/docs/how-to/http-bridge.mdx @@ -77,7 +77,7 @@ curl -X POST \ -H "X-Auth-Secret: uOGQyYzRhYWQwNmY3NtEwOTg1ZWU0NDU0NjByNTg2ZGE" \ -H "Authorization: uOqJlcm9vdHOB2CpYKQABcRIgYVymlT6sxiDd45CA0f..." \ ... -https://up.web3.storage/bridge +https://up.storacha.network/bridge ``` ## Listing Uploads @@ -108,13 +108,13 @@ curl -X POST \ -H "X-Auth-Secret: uOGQyYzRhYWQwNmY3NtEwOTg1ZWU0NDU0NjByNTg2ZGE" \ -H "Authorization: uOqJlcm9vdHOB2CpYKQABcRIgYVymlT6sxiDd45CA0f..." \ -d @list.json \ -https://up.web3.storage/bridge +https://up.storacha.network/bridge ``` ## Storing Files You can store individual files as [big as 5GB](https://github.com/web3-storage/w3infra/blob/26106e315e79bf8072d2bd052786e46563d9a1da/upload-api/service.js#L12-L16) in -spaces on web3.storage. To store larger files, see the [Sharded Uploads](#sharded-uploads) section below. +spaces on Storacha. To store larger files, see the [Sharded Uploads](#sharded-uploads) section below. To upload a file to your space you'll first need convert it to a CAR. Assuming your file is named `hello.txt` you can first use [`ipfs-car`](https://github.com/web3-storage/ipfs-car) to create a CAR: @@ -177,7 +177,7 @@ curl -X POST \ -H "X-Auth-Secret: uOGQyYzRhYWQwNmY3NtEwOTg1ZWU0NDU0NjByNTg2ZGE" \ -H "Authorization: uOqJlcm9vdHOB2CpYKQABcRIgYVymlT6sxiDd45CA0f..." \ -d @store.json \ -https://up.web3.storage/bridge +https://up.storacha.network/bridge ``` You'll get a response that includes a number of different fields: @@ -189,7 +189,7 @@ You'll get a response that includes a number of different fields: "fx": { "fork": [] }, - "iss": "did:web:web3.storage", + "iss": "did:web:storacha.network", "meta": {}, "out": { "ok": { @@ -239,8 +239,8 @@ Please note that your storage space has been allocated at this point - if you fa The good news is that you can store the same file as many times as you like without being charged for any additional space. -Your bits are now on IPFS, en route to the Filecoin Network, _but they will not show up as uploads in your web3.storage account!_ To -finish "uploading" your file to web3.storage you'll need to register your upload as described in the next section. +Your bits are now on IPFS, en route to the Filecoin Network, _but they will not show up as uploads in your Storacha account!_ To +finish "uploading" your file to Storacha you'll need to register your upload as described in the next section. ## Registering Uploads @@ -281,7 +281,7 @@ curl -X POST \ -H "X-Auth-Secret: uOGQyYzRhYWQwNmY3NtEwOTg1ZWU0NDU0NjByNTg2ZGE" \ -H "Authorization: uOqJlcm9vdHOB2CpYKQABcRIgYVymlT6sxiDd45CA0f..." \ -d @upload.json \ -https://up.web3.storage/bridge +https://up..network/bridge ``` being sure to again replace `X-Auth-Secret` and `Authorization` with the values generated by `w3 bridge generate-tokens`. @@ -332,7 +332,7 @@ curl -X POST \ -H "X-Auth-Secret: uOGQyYzRhYWQwNmY3NtEwOTg1ZWU0NDU0NjByNTg2ZGE" \ -H "Authorization: uOqJlcm9vdHOB2CpYKQABcRIgYVymlT6sxiDd45CA0f..." \ -d @store-and-upload.json \ -https://up.web3.storage/bridge +https://up.storacha.network/bridge ``` being sure to again replace `X-Auth-Secret` and `Authorization` with the values generated by `w3 bridge generate-tokens`. @@ -346,7 +346,7 @@ You'll get a result that looks like this: "fx": { "fork": [] }, - "iss": "did:web:web3.storage", + "iss": "did:web:storacha.network", "meta": {}, "out": { "ok": { @@ -379,7 +379,7 @@ You'll get a result that looks like this: "fx": { "fork": [] }, - "iss": "did:web:web3.storage", + "iss": "did:web:storacha.network", "meta": {}, "out": { "ok": { @@ -534,7 +534,7 @@ Once you receive a response, you'll need to `PUT` each of the cars to their resp "fx": { "fork": [] }, - "iss": "did:web:web3.storage", + "iss": "did:web:storacha.network", "meta": {}, "out": { "ok": { @@ -567,7 +567,7 @@ Once you receive a response, you'll need to `PUT` each of the cars to their resp "fx": { "fork": [] }, - "iss": "did:web:web3.storage", + "iss": "did:web:storacha.network", "meta": {}, "out": { "ok": { @@ -600,7 +600,7 @@ Once you receive a response, you'll need to `PUT` each of the cars to their resp "fx": { "fork": [] }, - "iss": "did:web:web3.storage", + "iss": "did:web:storacha.network", "meta": {}, "out": { "ok": { @@ -633,7 +633,7 @@ Once you receive a response, you'll need to `PUT` each of the cars to their resp "fx": { "fork": [] }, - "iss": "did:web:web3.storage", + "iss": "did:web:storacha.network", "meta": {}, "out": { "ok": { diff --git a/src/pages/docs/how-to/list.mdx b/src/pages/docs/how-to/list.mdx index bff9c93..ccf266d 100644 --- a/src/pages/docs/how-to/list.mdx +++ b/src/pages/docs/how-to/list.mdx @@ -1,15 +1,15 @@ import { Callout } from 'nextra/components' -# How to list files uploaded to web3.storage +# How to list files uploaded to Storacha -In this how-to guide, you'll learn about the different ways that you can list the files that you've uploaded to web3.storage. Once you've stored some files using web3.storage, you'll want to see a list of what you've uploaded. There are two ways you can do this: +In this how-to guide, you'll learn about the different ways that you can list the files that you've uploaded to Storacha. Once you've stored some files using Storacha, you'll want to see a list of what you've uploaded. There are two ways you can do this: - Programmatically using the JS client or CLI -- Using the web3.storage console +- Using the Storacha console ## Using the JS client or CLI -You can also access a listing of your uploads from your code using the web3.storage client. In the example below, this guide walks through how to use the JavaScript client library to fetch a complete listing of all the data you've uploaded using web3.storage. +You can also access a listing of your uploads from your code using the Storacha client. In the example below, this guide walks through how to use the JavaScript client library to fetch a complete listing of all the data you've uploaded using Storacha. For instructions on how to set up your client instance or CLI, check out the [Upload](/docs/how-to/upload/) section. @@ -43,6 +43,6 @@ You can learn about the relationship between uploads and shards in the [Upload v ## Using the console web UI -You can see a list of everything you've uploaded to web3.storage in the [console](https://console.web3.storage) web app. If you don't need to work with this list programmatically, using the website may be a simpler choice. +You can see a list of everything you've uploaded to Storacha in the [console](https://console.storacha.network) web app. If you don't need to work with this list programmatically, using the website may be a simpler choice. -This console provides a convenient overview of your stored data, including links to view your files in your browser via an [IPFS gateway](https://docs.ipfs.io/concepts/ipfs-gateway/) and information about how the data is being stored on the decentralized storage networks that web3.storage uses under the hood. +This console provides a convenient overview of your stored data, including links to view your files in your browser via an [IPFS gateway](https://docs.ipfs.io/concepts/ipfs-gateway/) and information about how the data is being stored on the decentralized storage networks that Storacha uses under the hood. diff --git a/src/pages/docs/how-to/receipts.md b/src/pages/docs/how-to/receipts.md index 626454a..f360c9b 100644 --- a/src/pages/docs/how-to/receipts.md +++ b/src/pages/docs/how-to/receipts.md @@ -1,6 +1,6 @@ # Querying UCAN receipts -You'll be able to get the receipt for a given task. This is especially useful for getting more information about async tasks that are found in receipts for other UCAN invocations. To read more about how web3.storage uses UCANs and why they're so useful, check out the UCANs and web3.storage section. +You'll be able to get the receipt for a given task. This is especially useful for getting more information about async tasks that are found in receipts for other UCAN invocations. To read more about how Storacha uses UCANs and why they're so useful, check out the UCANs and Storacha section. e.g. in the case of `filecoin/offer`, you'll get an instant receipt with an async task of `filecoin/accept`. diff --git a/src/pages/docs/how-to/remove.mdx b/src/pages/docs/how-to/remove.mdx index 010ad0e..2fec231 100644 --- a/src/pages/docs/how-to/remove.mdx +++ b/src/pages/docs/how-to/remove.mdx @@ -13,17 +13,17 @@ Note that there is a minimum 30 day retention period for uploaded data, and even **Permanent Data ♾️**
- Removing files from w3up will remove them from the file listing for your account, but that doesn't prevent nodes on the decentralized storage network from retaining copies of the data indefinitely. web3.storage itself generally retains and charges users for any uploaded data for a minimum of 30 days. Do not use w3up for data that may need to be permanently deleted in the future. + Removing files from w3up will remove them from the file listing for your account, but that doesn't prevent nodes on the decentralized storage network from retaining copies of the data indefinitely. Storacha itself generally retains and charges users for any uploaded data for a minimum of 30 days. Do not use w3up for data that may need to be permanently deleted in the future. ## Removing uploads (content CIDs) vs. stores (shard CIDs) -web3.storage tracks two different things for its users to support content addressing. These concepts were first introduced in the Upload section: +Storacha tracks two different things for its users to support content addressing. These concepts were first introduced in the Upload section: - **Content CIDs**: The CIDs used to reference and access uploads in the format generally useful to users (e.g., files, directories). These CIDs are usually prefixed by `bafy…` or `bafk…`. -- **Shard CIDs**: The CID of the serialized shards of data itself (CAR files) that are produced client-side, sent to web3.storage, and stored. These CIDs are prefixed by `bag…`. +- **Shard CIDs**: The CID of the serialized shards of data itself (CAR files) that are produced client-side, sent to Storacha, and stored. These CIDs are prefixed by `bag…`. -web3.storage tracks usage for payment (i.e., how much storage is utilized by a user) using the volume of data associated with shard CIDs. However, in general, most users will be interacting with content CIDs (this is how you fetch your data from the network), with shard CIDs more of an implementation detail (how data gets chunked, serialized into CAR files, and stored for uploads). +Storacha tracks usage for payment (i.e., how much storage is utilized by a user) using the volume of data associated with shard CIDs. However, in general, most users will be interacting with content CIDs (this is how you fetch your data from the network), with shard CIDs more of an implementation detail (how data gets chunked, serialized into CAR files, and stored for uploads). Fortunately, this shouldn't make things any more complicated - we go into more detail below, but in general, when you remove a content CID from your account, you'll want to remove the shard CIDs as well (e.g., in the client calling `client.remove(contentCID, { shards: true })`). @@ -36,7 +36,7 @@ If you followed the Upload section, you should already have your client or CLI s - Client: `client.remove(contentCID)` - CLI: `w3 rm ` -If you initially uploaded your content by using the recommended upload methods (e.g., used `Client.upload()` or `w3 up`) and didn't interact with CAR shards at all when uploading, we recommend removing the shard CIDs associated with the content CID from your account. Otherwise, you will still be paying for the data stored with web3.storage (as mentioned above). The easiest way to do that is to set the `shards` option to `true`: +If you initially uploaded your content by using the recommended upload methods (e.g., used `Client.upload()` or `w3 up`) and didn't interact with CAR shards at all when uploading, we recommend removing the shard CIDs associated with the content CID from your account. Otherwise, you will still be paying for the data stored with Storacha (as mentioned above). The easiest way to do that is to set the `shards` option to `true`: - Client: `client.remove(contentCID, { shards: true })` - CLI: `w3 rm --shards` diff --git a/src/pages/docs/how-to/retrieve.mdx b/src/pages/docs/how-to/retrieve.mdx index 4897c49..d150dab 100644 --- a/src/pages/docs/how-to/retrieve.mdx +++ b/src/pages/docs/how-to/retrieve.mdx @@ -1,10 +1,10 @@ import { Callout } from 'nextra/components' -# How to retrieve data from web3.storage +# How to retrieve data from Storacha -In this how-to guide, you'll learn several methods for retrieving data from web3.storage. +In this how-to guide, you'll learn several methods for retrieving data from Storacha. -All data stored using web3.storage is made available for retrieval via [IPFS](https://ipfs.io/), the InterPlanetary File System. IPFS is a distributed, peer-to-peer network for storing and sharing content-addressed data. This guide shows you several ways to retrieve your data from IPFS: +All data stored using Storacha is made available for retrieval via [IPFS](https://ipfs.io/), the InterPlanetary File System. IPFS is a distributed, peer-to-peer network for storing and sharing content-addressed data. This guide shows you several ways to retrieve your data from IPFS: - In your browser using an [HTTP gateway](/docs/how-to/retrieve/#using-an-ipfs-http-gateway). - Using the [Saturn dCDN](https://saturn.tech/). @@ -15,7 +15,7 @@ When retrieving any data, you'll be using the content CID of the upload (prefixe ## Using an IPFS HTTP gateway -You can easily fetch any data stored using web3.storage using an IPFS HTTP gateway. Because IPFS is a peer-to-peer, decentralized network, you can use any public HTTP gateway to fetch your data. In this guide, we'll use the gateway at w3s.link (which is optimized for data stored with web3.storage), but you can see more worldwide gateways on the [IPFS Public Gateway Checker](https://ipfs.github.io/public-gateway-checker/). +You can easily fetch any data stored using Storacha using an IPFS HTTP gateway. Because IPFS is a peer-to-peer, decentralized network, you can use any public HTTP gateway to fetch your data. In this guide, we'll use the gateway at w3s.link (which is optimized for data stored with Storacha), but you can see more worldwide gateways on the [IPFS Public Gateway Checker](https://ipfs.github.io/public-gateway-checker/). You can use an IPFS gateway to view a list of all the files in that directory from your browser. To do so, simply create a gateway URL. For example, if your CID is `bafybeidd2gyhagleh47qeg77xqndy2qy3yzn4vkxmk775bg2t5lpuy7pcu`, you can make a URL for the w3s.link gateway as follows: @@ -29,7 +29,7 @@ https://bafybeidd2gyhagleh47qeg77xqndy2qy3yzn4vkxmk775bg2t5lpuy7pcu.ipfs.w3s.lin If you want to link directly to a file within that directory, just add the file path after the CID portion of the link. For example: [bafybeidd2gyhagleh47qeg77xqndy2qy3yzn4vkxmk775bg2t5lpuy7pcu.ipfs.w3s.link/not-distributed.jpg](https://bafybeidd2gyhagleh47qeg77xqndy2qy3yzn4vkxmk775bg2t5lpuy7pcu.ipfs.w3s.link/not-distributed.jpg) could be used as a shareable link for your new favorite wallpaper. - Your web3.storage console page includes IPFS gateway links to all the content you've uploaded. + Your Storacha console page includes IPFS gateway links to all the content you've uploaded. ### Setting the filename @@ -40,7 +40,7 @@ https://bafybeicfnbaeigdtklwkrj35r4wtfppix732zromsadvgiu33mowah74yq.ipfs.w3s.lin In the link above, the CID `bafybeicfnbaeigdtklwkrj35r4wtfppix732zromsadvgiu33mowah74yq` points to an IPFS directory listing, which maps from the filename treehouse.jpeg to the CID for the image itself. -Since the web3.storage client wraps your uploaded files in a directory by default, this is the most common kind of gateway link you're likely to need, and your users should get nice filenames when they download their content. +Since the Storacha client wraps your uploaded files in a directory by default, this is the most common kind of gateway link you're likely to need, and your users should get nice filenames when they download their content. However, the behavior is a bit different if you make a gateway link directly to the image CID: @@ -90,7 +90,7 @@ Replace ``, ``, and `` with their respective v | Variable | Replace with | Example | | --- | --- | --- | | `` | The CID of the file you want to download. | `bafybeie2bjap32zi2yqh5jmpve5n jwulnkualcbiszvwfu36jzjyqskceq` | -| `` | The _name_ of the file that you originally uploaded to web3.storage. | `example.txt` | +| `` | The _name_ of the file that you originally uploaded to Storacha. | `example.txt` | | `` | The path and filename that you want curl to save the file to. This can be different to ``. | `./output-file.txt` | ## Next steps diff --git a/src/pages/docs/how-to/upload.mdx b/src/pages/docs/how-to/upload.mdx index 7c230e1..c3f5b6c 100644 --- a/src/pages/docs/how-to/upload.mdx +++ b/src/pages/docs/how-to/upload.mdx @@ -1,10 +1,10 @@ import { Callout } from 'nextra/components' -# How to upload data using web3.storage +# How to upload data using Storacha -In this how-to guide, you'll learn how to store data programmatically for your development projects using the web3.storage client library in JavaScript using your (developer-owned) Space. This includes various architecture options for the data pipeline for your users to upload to web3.storage, which then makes your data available on the decentralized IPFS network with persistent long-term storage provided by Filecoin. +In this how-to guide, you'll learn how to store data programmatically for your development projects using the Storacha client library in JavaScript using your (developer-owned) Space. This includes various architecture options for the data pipeline for your users to upload to Storacha, which then makes your data available on the decentralized IPFS network with persistent long-term storage provided by Filecoin. -Later in this section, we also cover uploading data using the CLI or web console. If you just want to quickly store a few files using web3.storage rather than include upload functionality in an app or service you're building, you may want to hop down there. +Later in this section, we also cover uploading data using the CLI or web console. If you just want to quickly store a few files using Storacha rather than include upload functionality in an app or service you're building, you may want to hop down there. **Public Data 🌎**
@@ -13,7 +13,7 @@ Later in this section, we also cover uploading data using the CLI or web console **Permanent Data ♾️**
- Removing files from w3up will remove them from the file listing for your account, but that doesn't prevent nodes on the decentralized storage network from retaining copies of the data indefinitely. web3.storage itself generally retains and charges users for any uploaded data for a minimum of 30 days. Do not use w3up for data that may need to be permanently deleted in the future. + Removing files from w3up will remove them from the file listing for your account, but that doesn't prevent nodes on the decentralized storage network from retaining copies of the data indefinitely. Storacha itself generally retains and charges users for any uploaded data for a minimum of 30 days. Do not use w3up for data that may need to be permanently deleted in the future. ## Using the CLI @@ -38,7 +38,7 @@ There are a few useful flags (check out the reference docs or `w3 up --help` to ### Installing the client -In your JavaScript project, add the web3.storage package to your dependencies: +In your JavaScript project, add the Storacha package to your dependencies: ```sh npm install @web3-storage/w3up-client @@ -70,15 +70,15 @@ A new client can claim access to their existing Spaces by validating their email ```mermaid sequenceDiagram -Client-\>\>web3.storage service: Here is my email address and Agent DID -web3.storage service--\>\>Client: Please click the link to validate -Client--\>\>web3.storage service: Email address validated -web3.storage 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 web3.storage'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). +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). -When a Space is created, access permissions are delegated to your email address. We use a special kind of DID for this, a `did:mailto:`. These UCANs are stashed with the web3.storage service. When you validate your email address with a new Agent DID, web3.storage issues a UCAN attestation, that says your Agent DID is owned by your email address. It also returns the UCAN permissions you previously stashed. You can then use the returned UCANs, along with the attestation to prove you are authorized to perform actions. +When a Space is created, access permissions are delegated to your email address. We use a special kind of DID for this, a `did:mailto:`. These UCANs are stashed with the Storacha service. When you validate your email address with a new Agent DID, Storacha issues a UCAN attestation, that says your Agent DID is owned by your email address. It also returns the UCAN permissions you previously stashed. You can then use the returned UCANs, along with the attestation to prove you are authorized to perform actions. ```javascript import { create } from '@web3-storage/w3up-client' @@ -157,21 +157,21 @@ async function main () { } ``` -### Uploading to web3.storage +### Uploading to S Now that your client instance is setup to interact with your Space, you're ready to upload! Call `uploadFile` to upload a single file, or `uploadDirectory` to upload multiple files. There are two main options to getting content into your Space: -- Upload data to web3.storage from the backend client itself (e.g., you're storing data that your users are uploading to your backend) -- Upload data to web3.storage directly from your user's environment (like your application's user's browser) by delegating a UCAN that has permission to upload to your Space +- Upload data to Storacha from the backend client itself (e.g., you're storing data that your users are uploading to your backend) +- Upload data to Storacha directly from your user's environment (like your application's user's browser) by delegating a UCAN that has permission to upload to your Space ### Upload from backend client directly ```mermaid sequenceDiagram User-\>\>Application Backend: Upload data -Application Backend-\>\>web3.storage service: 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. @@ -196,11 +196,11 @@ In the example above, `directoryCid` resolves to an IPFS directory. sequenceDiagram participant User participant Application Backend -participant web3.storage service +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-\>\>web3.storage service: Upload data +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. @@ -270,7 +270,7 @@ async function frontend() { You are now ready to upload using the client! In general, the easiest way to upload data is using the `uploadFile` or `uploadDirectory` method. -`uploadFile` expects a "Blob like" input, which can be a [Blob](https://developer.mozilla.org/en-US/docs/Web/API/Blob) or [File](https://developer.mozilla.org/en-US/docs/Web/API/File) when running in a browser. On Node.js, see the [`files-from-path` library](https://github.com/web3-storage/files-from-path), which can load compatible objects from the local filesystem. By default, files uploaded to web3.storage will be wrapped in an IPFS directory listing. This preserves the original filename and makes links more human-friendly than CID strings, which look like random gibberish. +`uploadFile` expects a "Blob like" input, which can be a [Blob](https://developer.mozilla.org/en-US/docs/Web/API/Blob) or [File](https://developer.mozilla.org/en-US/docs/Web/API/File) when running in a browser. On Node.js, see the [`files-from-path` library](https://github.com/web3-storage/files-from-path), which can load compatible objects from the local filesystem. By default, files uploaded to Storacha will be wrapped in an IPFS directory listing. This preserves the original filename and makes links more human-friendly than CID strings, which look like random gibberish. `uploadDirectory` requires `File`-like objects instead of `Blob`s, as the file's name property is used to build the directory hierarchy. @@ -337,7 +337,7 @@ In Node.js, the [`files-from-path` library](https://github.com/web3-storage/file import { filesFromPaths } from 'files-from-path' ``` -You can also manually create File objects by importing a Node.js implementation of File from the web3.storage package. This is useful when you want to store data created by your application, instead of files from the user's computer. +You can also manually create File objects by importing a Node.js implementation of File from the Storacha package. This is useful when you want to store data created by your application, instead of files from the user's computer. ```javascript async function getFiles (path) { diff --git a/src/pages/docs/how-to/w3name.mdx b/src/pages/docs/how-to/w3name.mdx index ce21e6c..4b79f95 100644 --- a/src/pages/docs/how-to/w3name.mdx +++ b/src/pages/docs/how-to/w3name.mdx @@ -2,7 +2,7 @@ import { Callout } from 'nextra/components' # Update your data with w3name -All the data you [store on web3.storage](upload) is [content-addressed](../concepts/content-addressing), which means that you always get location-independent, cryptographically verifiable links to your content. +All the data you [store on Storacha](upload) is [content-addressed](../concepts/content-addressing), which means that you always get location-independent, cryptographically verifiable links to your content. Content addressing is a very powerful tool, but because the address is directly derived from the content, it is limited by definition to content that already exists, and any changes to the content will result in an entirely new address. @@ -12,15 +12,15 @@ When you need to refer to something that might change over time, or that may not All records created and updated using w3name are signed locally with each user's private publishing key. This means that the w3name service never sees your keys, and it also doesn't require any authentication to use - no account or API keys required! -In this guide, we'll discover how to use the JavaScript `w3name` package to create and manage name records for data stored with web3.storage. +In this guide, we'll discover how to use the JavaScript `w3name` package to create and manage name records for data stored with Storacha. - IPNS is a secure, local-first protocol, but does not always resolve performantly when needing to fetch the absolute latest update to a name (which is a requirement for most application use-cases) from the public IPFS network (e.g., over a local Kubo instance or public gateway). You can read more about this [here.](https://docs.ipfs.tech/concepts/ipns/#tradeoffs-between-consistency-vs-availability). As a result, w3name's recommended usage for use cases where performance and consistency are both important is [via an endpoint hosted by web3.storage](#getting-the-latest-revision). We plan on offering a new naming protocol at some point that can be used for application use cases without relying on any centralized infrastructure. + IPNS is a secure, local-first protocol, but does not always resolve performantly when needing to fetch the absolute latest update to a name (which is a requirement for most application use-cases) from the public IPFS network (e.g., over a local Kubo instance or public gateway). You can read more about this [here.](https://docs.ipfs.tech/concepts/ipns/#tradeoffs-between-consistency-vs-availability). As a result, w3name's recommended usage for use cases where performance and consistency are both important is [via an endpoint hosted by Storacha](#getting-the-latest-revision). We plan on offering a new naming protocol at some point that can be used for application use cases without relying on any centralized infrastructure. ## What's in a name? -w3name is similar to the Domain Name System (DNS), in that it allows you to query for an identifier and resolve the latest value. Unlike DNS, however, you cannot choose your own identifiers, and the "names" produced by IPNS and w3name are not human-readable, like `web3.storage` or `ipfs.io`. +w3name is similar to the Domain Name System (DNS), in that it allows you to query for an identifier and resolve the latest value. Unlike DNS, however, you cannot choose your own identifiers, and the "names" produced by IPNS and w3name are not human-readable, like `storacha` or `ipfs.io`. The "names" in IPNS and w3name are unique identifiers, and each one is a string representation of the public half of a cryptographic key-pair. diff --git a/src/pages/docs/index.mdx b/src/pages/docs/index.mdx index 12cba96..ef3d194 100644 --- a/src/pages/docs/index.mdx +++ b/src/pages/docs/index.mdx @@ -4,9 +4,9 @@ title: docs import { Cards, Card } from 'nextra/components' -**Under the hood** web3.storage uses [UCANs](https://github.com/ucan-wg/spec) for trustless, local-first authorization, and is backed by the provable storage of [IPFS](https://docs.ipfs.tech/) and [Filecoin](https://docs.filecoin.io/basics/what-is-filecoin). +**Under the hood** Storacha uses [UCANs](https://github.com/ucan-wg/spec) for trustless, local-first authorization, and is backed by the provable storage of [IPFS](https://docs.ipfs.tech/) and [Filecoin](https://docs.filecoin.io/basics/what-is-filecoin). -When it comes down to building your next application, service, or website, web3.storage keeps it simple. You get all the benefits of decentralized storage technologies with the frictionless experience you expect in a modern dev workflow. **All you need to use web3.storage is a key-pair and your data.** +When it comes down to building your next application, service, or website, Storacha keeps it simple. You get all the benefits of decentralized storage technologies with the frictionless experience you expect in a modern dev workflow. **All you need to use Storacha is a key-pair and your data.** Building a **JavaScript** or **TypeScript** app? see our [guide to using w3up-client](/docs/w3up-client). diff --git a/src/pages/docs/privacy-policy.md b/src/pages/docs/privacy-policy.md index c82e202..b0c6a2f 100644 --- a/src/pages/docs/privacy-policy.md +++ b/src/pages/docs/privacy-policy.md @@ -2,7 +2,7 @@ ## Privacy -This Privacy Policy governs all use of the web3.storage website (“web3.storage” or the “Website”), the w3link/w3s.link gateway (“Gateway”) and all content, services and products available at or through the Website or Gateway (collectively, “Services”). +This Privacy Policy governs all use of the Storacha website (“Storacha” or the “Website”), the w3link/w3s.link gateway (“Gateway”) and all content, services and products available at or through the Website or Gateway (collectively, “Services”). The Services are offered subject to your acceptance without modification of all the terms and conditions herein, and all other other operating rules, policies (including, without limitation, our [Terms of Service](/docs/terms/) and procedures that may be updated from time to time. By accessing or using any part of our Services you agree to be bound by the terms and conditions of the Privacy Policy. If you do not agree to all of the terms and conditions of this Privacy Policy, then you may not access our Services. @@ -19,7 +19,7 @@ This Privacy Policy applies to our collection, use, and disclosure of the person We are a conduit for information controlled by others. It is our users who are responsible for the user-uploaded and/or community-hosted content transmitted across our network (e.g., images, written content, graphics, etc.). -This Privacy Policy also does not apply to any third-party domains, websites, APIs, applications, and networks, even if linked via the web3.storage website, as these third-party properties may have their own terms and privacy policies. +This Privacy Policy also does not apply to any third-party domains, websites, APIs, applications, and networks, even if linked via the Storacha website, as these third-party properties may have their own terms and privacy policies. ### What information do we collect and on what basis? @@ -94,11 +94,11 @@ During your use of our Services and your interactions with us, your personal inf ### California Statement -If you are a resident of California, you have the right to request what information we collect, use, and disclose. Please see “What information do we collect and on what basis?” for a description of the data we have collected over the preceding 12 months. You also have the right to request that we delete your information. We do not sell your personal information. To make a request, you, or your agent, can contact us at support@web3.storage. Please note that we may still require you to verify your identity before we process a request. We will not discriminate against you because you have exercised any of your privacy rights under the CCPA. We currently do not respond to Do-Not-Track requests. +If you are a resident of California, you have the right to request what information we collect, use, and disclose. Please see “What information do we collect and on what basis?” for a description of the data we have collected over the preceding 12 months. You also have the right to request that we delete your information. We do not sell your personal information. To make a request, you, or your agent, can contact us at support@storacha.network Please note that we may still require you to verify your identity before we process a request. We will not discriminate against you because you have exercised any of your privacy rights under the CCPA. We currently do not respond to Do-Not-Track requests. ### Contact Us -Questions about our Privacy Policy? Please contact support@web3.storage. +Questions about our Privacy Policy? Please contact support@storacha.network ### Changes to our Privacy Policy diff --git a/src/pages/docs/quickstart.md b/src/pages/docs/quickstart.md index 6925ccf..efd1ff1 100644 --- a/src/pages/docs/quickstart.md +++ b/src/pages/docs/quickstart.md @@ -1,13 +1,13 @@ # Quickstart -Ready to get started using web3.storage? Get up and running in minutes by following this quickstart guide. In this guide, we'll walk through the following steps: +Ready to get started using Storacha? Get up and running in minutes by following this quickstart guide. In this guide, we'll walk through the following steps: 1. Install the CLI. -2. Create a Space to upload your files and register it with web3.storage. +2. Create a Space to upload your files and register it with Storacha. 3. Upload a file. 4. Get your uploaded file using your browser or curl. -This guide uses our CLI, w3cli, since it's the fastest way to get started using web3.storage. In the "How-to" section of the docs, we also include instructions on using the Javascript client or web interface to create an account, store data, and more. +This guide uses our CLI, w3cli, since it's the fastest way to get started using Storacha. In the "How-to" section of the docs, we also include instructions on using the Javascript client or web interface to create an account, store data, and more. ## You will need @@ -28,7 +28,7 @@ npm install -g @web3-storage/w3cli ## Create an account -You need to create a web3.storage account associated with an email address and set it up so you can start uploading to a Space. The Space is created locally and associated with a private key, and is then registered with web3.storage and associated with your email address. But don't worry about keeping track of the Space's private key! web3.storage's email authorization system allows this private key to be treated as a throwaway key. +You need to create a Storacha account associated with an email address and set it up so you can start uploading to a Space. The Space is created locally and associated with a private key, and is then registered with Storacha and associated with your email address. But don't worry about keeping track of the Space's private key! Storacha's email authorization system allows this private key to be treated as a throwaway key. 1. Run `w3 login alice@example.com` in the command line using your email address. This will send an email to your inbox with a link for validation. 2. Once you click on the validation link, you'll be taken to a webpage where you can select a plan (like our Starter tier). @@ -49,7 +49,7 @@ w3 up lets-go.txt ⁂ https://w3s.link/ipfs/bafybeib4ht2a53pttgipw6mgckqqhmgkifnmh2glzsju2c6ait5ibnkow4 ``` -The CLI content-addresses your files, packs them into 1 or more CAR files, and uploads them to web3.storage for indexing and inclusion in Filecoin storage deals. It will show an HTTP gateway URL that includes the content CID (content identifier) of your upload e.g: +The CLI content-addresses your files, packs them into 1 or more CAR files, and uploads them to Storacha for indexing and inclusion in Filecoin storage deals. It will show an HTTP gateway URL that includes the content CID (content identifier) of your upload e.g: https://w3s.link/ipfs/bafybeib4ht2a53pttgipw6mgckqqhmgkifnmh2glzsju2c6ait5ibnkow4 @@ -59,7 +59,7 @@ https://w3s.link/ipfs/bafybeib4ht2a53pttgipw6mgckqqhmgkifnmh2glzsju2c6ait5ibnkow ## Get your file -Your upload is now available over the public IPFS network using the content CID of your upload. The easiest way to fetch it is using the link that `w3 up` provided to the w3s.link gateway. w3s.link is optimized for content uploaded to web3.storage. +Your upload is now available over the public IPFS network using the content CID of your upload. The easiest way to fetch it is using the link that `w3 up` provided to the w3s.link gateway. w3s.link is optimized for content uploaded to Storacha. ```sh curl -L 'https://w3s.link/ipfs/bafybeib4ht2a53pttgipw6mgckqqhmgkifnmh2glzsju2c6ait5ibnkow4/lets-go.txt' @@ -87,9 +87,9 @@ __ _ __ ____ \_ |__ \_____ \ _______/ |_ ____ _______ _____ ## Next steps -Congratulations! You've just covered the basics of web3.storage. To learn more, take a look at these useful resources: +Congratulations! You've just covered the basics of Storacha. To learn more, take a look at these useful resources: - For a deep dive into storing files, including using the Javascript client to do so, visit the [Upload how-to guide](/docs/how-to/upload). -- Read more about the power of [UCANs and IPFS](/docs/concepts/ucans-and-web3storage), and learn about the various options to integrate web3.storage with your application. - +- Read more about the power of [UCANs and IPFS](/docs/concepts/ucans-and-web3storage), and learn about the various options to integrate Storacha with your application. + diff --git a/src/pages/docs/service-level-agreement.md b/src/pages/docs/service-level-agreement.md index cdd70d8..4022546 100644 --- a/src/pages/docs/service-level-agreement.md +++ b/src/pages/docs/service-level-agreement.md @@ -1,8 +1,8 @@ # Business Service Level Agreement -## 1. web3.storage Service Level Agreement ("SLA"). +## 1. Storacha Service Level Agreement ("SLA"). -Nitro Data LLC ("Company") commits to provide a level of service for web3.storage Customers demonstrating: +Nitro Data LLC ("Company") commits to provide a level of service for Storacha Customers demonstrating: 1.1 99.9% Uptime. The Upload Service will upload Customer Content at least 99.9% of the time and the Read Service will serve Customer Content at least 99.9% of the time, subject to Section 4. @@ -10,7 +10,7 @@ Nitro Data LLC ("Company") commits to provide a level of service for web3.storag 1.3 Upload Size Limit. Individual uploads to the Upload Service may encounter issues if they are over 750GB. -1.4 Tier-Based Size Limit. Individual uploads are subject to size limits based on Customer’s chosen pricing tier as described in the Pricing page available at . +1.4 Tier-Based Size Limit. Individual uploads are subject to size limits based on Customer’s chosen pricing tier as described in the Pricing page available at . ## 2. Definitions. @@ -32,9 +32,9 @@ Nitro Data LLC ("Company") commits to provide a level of service for web3.storag 2.9 "Services" means, collectively, the Upload Service and the Read Service. -2.10 “Upload Service” refers to uploads through the website, client, and CLI for supported file types and sizes as defined by the docs available at https://web3.storage/docs/. +2.10 “Upload Service” refers to uploads through the website, client, and CLI for supported file types and sizes as defined by the docs available at https://storacha/docs/. -2.11 “Read Service” refers to reading successfully uploaded data, using its CID, over [w3link](https://web3.storage/products/w3link/) or via Bitswap using IPFS nodes peered with web3.storage nodes. +2.11 “Read Service” refers to reading successfully uploaded data, using its CID, over [w3link](https://storacha/products/w3link/) or via Bitswap using IPFS nodes peered with Storacha nodes. 2.12 "Service Discount" is the percentage of the monthly service fees for the Services deducted from Customer’s next monthly bill for a validated Claim. @@ -48,7 +48,7 @@ Nitro Data LLC ("Company") commits to provide a level of service for web3.storag 3.2 In order to be eligible to submit a Claim with respect to any Incident, the Customer must first have notified Customer Support of the Incident, using the procedures set forth by Company in Section 3.3, within five business days following the Incident. -3.3 To submit a Claim, Customer must contact Customer Support at support@web3.storage and provide notice of its intention to submit a Claim. Customer must provide to Customer Support all reasonable details regarding the Claim, including but not limited to, detailed descriptions of the Incident(s), the duration of the Incident, network traceroutes, the Content ID(s) or file(s) affected and any attempts made by Customer to resolve the Incident. +3.3 To submit a Claim, Customer must contact Customer Support at support@storacha.network and provide notice of its intention to submit a Claim. Customer must provide to Customer Support all reasonable details regarding the Claim, including but not limited to, detailed descriptions of the Incident(s), the duration of the Incident, network traceroutes, the Content ID(s) or file(s) affected and any attempts made by Customer to resolve the Incident. 3.4 In order for Company to consider a Claim, Customer must submit the Claim, including sufficient evidence to support the Claim, by the end of the billing month following the billing month in which the Incident which is the subject of the Claim occurs. @@ -72,11 +72,11 @@ Nitro Data LLC ("Company") commits to provide a level of service for web3.storag (g) Caused by timeouts caused by tooling used by the Customer; -(i) Caused by Customer attempting to upload files via the web3.storage website; +(i) Caused by Customer attempting to upload files via the Storacha website; -(j) Due to failures of infrastructure used to read data from web3.storage, including inaccessibility of public gateways; +(j) Due to failures of infrastructure used to read data from Storacha, including inaccessibility of public gateways; -(k) That resulted from Customer’s use of gateways not peered with web3.storage (i.e., not listed on ); +(k) That resulted from Customer’s use of gateways not peered with Storacha (i.e., not listed on ); (l) That resulted from a brief delay in data availability on IPFS following initial data upload and indexing. diff --git a/src/pages/docs/terms.md b/src/pages/docs/terms.md index c7e1c29..c996fa8 100644 --- a/src/pages/docs/terms.md +++ b/src/pages/docs/terms.md @@ -1,8 +1,8 @@ # Terms of service + -\[If you are still using the legacy web3.storage API (e.g., you created an account before November 14, 2023), please view the applicable Terms of Service [here](https://old.web3.storage/terms/).] - -The following terms and conditions govern all use of the web3.storage website (“web3.storage” or the “Website”), the w3link/w3s.link gateway (“Gateway”) and all content, services and products available at or through the Website or Gateway (collectively, “Services”). The Services are offered subject to your acceptance without modification of all of the terms and conditions contained herein. As all data uploaded to web3.storage will be available via IPFS, the Services are also subject to the [Terms of Service of IPFS.io](https://discuss.ipfs.tech/tos) and [Privacy Policy of IPFS.io](https://discuss.ipfs.tech/privacy). +The following terms and conditions govern all use of the Storacha website (“Storacha” or the “Website”), the w3link/w3s.link gateway (“Gateway”) and all content, services and products available at or through the Website or Gateway (collectively, “Services”). The Services are offered subject to your acceptance without modification of all of the terms and conditions contained herein. As all data uploaded to storacha will be available via IPFS, the Services are also subject to the [Terms of Service of IPFS.io](https://discuss.ipfs.tech/tos) and [Privacy Policy of IPFS.io](https://discuss.ipfs.tech/privacy). If you do not agree to all the terms and conditions of this agreement (“Agreement” or “TOS”), then you may not access the Website or use any of the Services. @@ -12,11 +12,11 @@ Nitro Data LLC (“we,” “us”) may make changes to this Agreement and prici Data stored via the Services will be available via IPFS and stored on Filecoin until the expiry of the respective deals. There may be a delay between content being uploaded via the Services and being stored on Filecoin through a deal. Additionally, you may experience minor delays immediately after uploading new content to the Services while this content becomes available on the IPFS network. -The maximum size of a registered upload is 750GB. Uploads greater than this size may not be registered successfully with your account, though if the data is successfully stored with web3.storage, you will still be responsible for paying for this storage. +The maximum size of a registered upload is 750GB. Uploads greater than this size may not be registered successfully with your account, though if the data is successfully stored with Storacha, you will still be responsible for paying for this storage. We reserve the right to terminate the Services at our sole discretion or to transfer operation of the Services to a third party or smart contract. Prior to termination or transfer, we will provide 90 days’ notice to users via email to allow users enough time to make arrangements if any (e.g. remote pinning to their own IPFS node, remote pinning to another service, or preparing to manage the renewal of their Filecoin deals on their own). -All data uploaded to web3.storage is available to anyone who requests it using the correct CID. **Users should not store any private or sensitive information in an unencrypted form using web3.storage.** Deleting files from web3.storage via the site's web console or API will remove them from the file listing for a user's account, but you may be charged for at least 30 days of storage for those files. Additionally, uploaded files typically remain on our infrastructure for at minimum thirty (30) days, and nodes on the IPFS network may retain copies of the data indefinitely. **Users should not use web3.storage to store data that may need to be permanently deleted in the future.** +All data uploaded to Storacha is available to anyone who requests it using the correct CID. **Users should not store any private or sensitive information in an unencrypted form using Storacha.** Deleting files from Storacha via the site's web console or API will remove them from the file listing for a user's account, but you may be charged for at least 30 days of storage for those files. Additionally, uploaded files typically remain on our infrastructure for at minimum thirty (30) days, and nodes on the IPFS network may retain copies of the data indefinitely. **Users should not use Storacha to store data that may need to be permanently deleted in the future.** ## Paid Accounts @@ -24,19 +24,19 @@ All data uploaded to web3.storage is available to anyone who requests it using t In order to begin storing files via the Services, you will need to provide us with one or more Payment Methods. "Payment Method" means a current, valid method of payment, which may involve a third party or payment processing vendor. You can increase your storage limit and add paid features to your account by signing up for a paid subscription plan (“Paid Plan”). -You agree that you’ll pay the amounts set forth in https://web3.storage/pricing/ for your chosen tier (“Subscription Charge”) plus any charges for additional usage beyond the storage limit of your selected tier during the previous month (“Overages”) (collectively, “Subscription Charge” and “Overages” are referred to as (the “Fees”) for each billing cycle). +You agree that you’ll pay the amounts set forth in https://storacha.network/pricing/ for your chosen tier (“Subscription Charge”) plus any charges for additional usage beyond the storage limit of your selected tier during the previous month (“Overages”) (collectively, “Subscription Charge” and “Overages” are referred to as (the “Fees”) for each billing cycle). -When determining tier storage limits and Overages, we track usage for payment using the volume of data associated with shard content identifiers/CIDs (CIDs referencing the actual data sent to web3.storage and stored) – usage is not tracked based on content CIDs (CIDs used to reference and access uploads in a format useful to users, like specific files and directories). +When determining tier storage limits and Overages, we track usage for payment using the volume of data associated with shard content identifiers/CIDs (CIDs referencing the actual data sent to Storacha and stored) – usage is not tracked based on content CIDs (CIDs used to reference and access uploads in a format useful to users, like specific files and directories). You authorize us to charge any Payment Method associated with your account in case your primary Payment Method is declined or no longer available to us for payment of Fees you owe us. You remain responsible for any uncollected Fees. If a payment is not successfully settled, due to expiration, insufficient funds, or otherwise, and you do not cancel your account, we may suspend your access to the Paid Plan until we have successfully charged a valid Payment Method. For some Payment Methods, the issuer may charge you additional fees, such as foreign transaction fees or other fees relating to the processing of your Payment Method. ### Cancellation -You can cancel your Paid Plan at any time, and you will be able to upload new Data to web3.storage through the end of your billing period. Payments are nonrefundable and there are no refunds or credits for partially used membership periods. After cancellation, data uploaded via a Paid Plan may not be available through our hosted IPFS infrastructure after the end of your billing period. +You can cancel your Paid Plan at any time, and you will be able to upload new Data to Storacha through the end of your billing period. Payments are nonrefundable and there are no refunds or credits for partially used membership periods. After cancellation, data uploaded via a Paid Plan may not be available through our hosted IPFS infrastructure after the end of your billing period. ### Plan Adjustments -You may change your chosen tier at any point. You will be charged for the tier you’re subscribed to at the time of billing (plus any Overages for stored content over that tier’s limit). By selecting your tier, you consent to the limits associated with your chosen tier (as set forth in https://web3.storage/pricing/); you also consent to the Overages described in this Agreement. +You may change your chosen tier at any point. You will be charged for the tier you’re subscribed to at the time of billing (plus any Overages for stored content over that tier’s limit). By selecting your tier, you consent to the limits associated with your chosen tier (as set forth in https://storacha.network/pricing/); you also consent to the Overages described in this Agreement. ### Changes @@ -48,7 +48,7 @@ The Fees do not include any taxes, levies, duties, or similar governmental asses ### Overages -You agree to pay the following Overages fees for storage amounts exceeding your selected tier (for more information on tiers, see https://web3.storage/pricing/). Overages will be billed to you at the beginning of your next billing cycle. +You agree to pay the following Overages fees for storage amounts exceeding your selected tier (for more information on tiers, see https://storacha.network/pricing/). Overages will be billed to you at the beginning of your next billing cycle. ## Acceptable Use @@ -61,7 +61,7 @@ Tricking users into revealing sensitive information to an unauthorized party (e. Naming your Content in a manner that misleads readers into thinking you are another person or company; Posting or distributing spam, including Content advertised via unwanted electronic messages on newsgroups, email lists, blogs, websites, and other unsolicited promotional materials; Unethical or unwanted commercial Content designed to drive traffic to third party sites or boost the search engine rankings of third party sites; -Interfering with or disrupting the Services, or creating an undue burden on the Services or the networks or services connected to the Services, including (a) activity impacting the service level of other web3.storage users or (b) via a distributed denial of service attack. +Interfering with or disrupting the Services, or creating an undue burden on the Services or the networks or services connected to the Services, including (a) activity impacting the service level of other Storacha users or (b) via a distributed denial of service attack. ### Infringement of Others’ Rights @@ -78,7 +78,7 @@ Using the Services in a way that is reasonably likely to cause or increase the r We have the right (though not the obligation) to, in our sole discretion (i) refuse or remove any Content; (ii) block uploads, or (iii) temporarily or permanently suspend access to your account if, in our reasonable opinion, there has been a breach of this TOS in any way for any reason. Additionally, we have the right to temporarily or permanently suspend access to accounts linked to temporary email addresses, email addresses created programmatically such as via bots, or hacked email addresses if we suspect these user accounts will be used in a manner that violates this TOS. We will have no obligation to provide any compensation or a refund of any amounts previously paid. -In order to use the Services you must be 13 years of age or older. If you are 13 or older but under 18 years of age, you must have your parent or legal guardian’s permission to use web3.storage and to accept the terms of this TOS. +In order to use the Services you must be 13 years of age or older. If you are 13 or older but under 18 years of age, you must have your parent or legal guardian’s permission to use Storacha and to accept the terms of this TOS. If you are on any U.S. or E.U. sanctions list, or residing in any U.S. or E.U.-sanctioned region, you may not participate in the Service. You further agree that you will not access the Services using any technology to circumvent applicable laws, such as sanctions laws. diff --git a/src/pages/docs/w3cli.mdx b/src/pages/docs/w3cli.mdx index dd8ec97..2bf2d94 100644 --- a/src/pages/docs/w3cli.mdx +++ b/src/pages/docs/w3cli.mdx @@ -2,7 +2,7 @@ import { Callout } from 'nextra/components' # `w3cli` -You can get started using web3.storage right away from your command line using `w3`, our command line interface tool. +You can get started using Storacha right away from your command line using `w3`, our command line interface tool. In this guide, we'll walk through the following steps: @@ -37,11 +37,11 @@ Once the install is complete, you'll have a `w3` command available. Try running Pre-compiled, standalone binaries are now available for MacOS, Linux and Windows: [Download latest release](https://github.com/web3-storage/go-w3up/releases/latest). -Please ensure you [read the documentation for using the Go CLI](https://github.com/web3-storage/go-w3up#cli). These binaries are built from the Go client codebase which is not as fully featured as the JS client. Currently to use the Go CLI tool you will need to obtain a delegation created by the JS CLI or [console](https://console.web3.storage). +Please ensure you [read the documentation for using the Go CLI](https://github.com/web3-storage/go-w3up#cli). These binaries are built from the Go client codebase which is not as fully featured as the JS client. Currently to use the Go CLI tool you will need to obtain a delegation created by the JS CLI or [console](https://console..network). ## Create your first space -When you upload things to web3.storage, each upload is associated with a "space", which is a unique identifier that acts as a namespace for your content. +When you upload things to Storacha, each upload is associated with a "space", which is a unique identifier that acts as a namespace for your content. Spaces are identified by DID using keys created locally on your devices. To use a space for uploads, it needs to be registered with the storage service by providing an email address. @@ -67,7 +67,7 @@ The `*` symbol indicates that the `Documents` space is currently active. If you ## Upload files -Now that you've [created and registered a space](#create-space), you're ready to upload files to web3.storage! +Now that you've [created and registered a space](#create-space), you're ready to upload files to Storacha! Use the `w3 up` command to upload a file or directory: diff --git a/src/pages/docs/w3up-client.md b/src/pages/docs/w3up-client.md index 4410ea2..5909beb 100644 --- a/src/pages/docs/w3up-client.md +++ b/src/pages/docs/w3up-client.md @@ -1,6 +1,6 @@ # `w3up-client` -You can easily integrate web3.storage into your JavaScript apps using `w3up-client`, our JavaScript client for the w3up platform. +You can easily integrate Storacha into your JavaScript apps using `w3up-client`, our JavaScript client for the w3up platform. In this guide, we'll walk through the following steps: @@ -36,7 +36,7 @@ See the [w3up-client README](https://github.com/web3-storage/w3up/blob/main/pack ## Create and provision a space -When you upload things to web3.storage, each upload is associated with a "space", which is a unique identifier that acts as a namespace for your content. Spaces are identified by DID using keys created locally on your devices. +When you upload things to Storacha, each upload is associated with a "space", which is a unique identifier that acts as a namespace for your content. Spaces are identified by DID using keys created locally on your devices. To create a space using `w3up-client`, use the `createSpace` client method: @@ -86,7 +86,7 @@ If your agent has no other spaces, saving the space will set it as the "current await client.setCurrentSpace(space.did()) ``` -One last thing - now that you've saved your space locally, it's a good idea to setup recovery via [web3.storage Account](https://github.com/web3-storage/specs/blob/main/w3-account.md), so that when you move to a different device you can still administer your space as long as you can log in to your web3.storage Account: +One last thing - now that you've saved your space locally, it's a good idea to setup recovery via [Storacha Account](https://github.com/web3-storage/specs/blob/main/w3-account.md), so that when you move to a different device you can still administer your space as long as you can log in to your Storacha Account: ```js const recovery = await space.createRecovery(myAccount.did()) @@ -100,7 +100,7 @@ await client.capability.access.delegate({ ## Upload files -Now that you've created and provisioned a space, you're ready to upload files to web3.storage! +Now that you've created and provisioned a space, you're ready to upload files to Storacha! Call `uploadFile` to upload a single file, or `uploadDirectory` to upload multiple files.