-
Notifications
You must be signed in to change notification settings - Fork 108
docs: sites introduction and troubleshooting docs for IA revision #3117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 1 commit
7bb7ad9
de79b01
821b6df
8d9e546
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,23 +1,51 @@ | ||
| --- | ||
| title: Walrus Sites | ||
| description: "Deploy decentralized websites on Walrus." | ||
| keywords: ["walrus", "walrus sites", "decentralized websites", "static sites", "sui", "site-builder", "portal", "suins", "web hosting"] | ||
| --- | ||
|
|
||
| {/* https://linear.app/mysten-labs/issue/DOCS-697/sitesindex */} | ||
|
|
||
| This tutorial walks you through the steps necessary to publish a Walrus Site. We also provide the | ||
| instructions on how to add a SuiNS name to it for convenient browsing. | ||
| Walrus Sites are decentralized websites built on [Sui](docs.sui.io) and Walrus. Your site's files are stored on Walrus, a decentralized storage network, while a Sui smart contract records ownership and maps each resource path to its content. Anyone can publish a Walrus Site using the [`site-builder` CLI tool](/docs/sites/getting-started/installing-the-site-builder) and browse it through a [portal](/docs/sites/portals/deploy-locally). | ||
|
|
||
| <Cards> | ||
| <Card title="Installing the Site Builder" href="/docs/sites/getting-started/installing-the-site-builder"> | ||
| Install and setup the Walrus Sites `site-builder` tool for development. | ||
|
|
||
| <Card title="Introduction" href="/docs/sites/introduction/"> | ||
| Learn what Walrus Sites are, how they work, and the key components that make up a site. | ||
| </Card> | ||
|
|
||
| <Card title="Publishing a Walrus Site" href="/docs/sites/getting-started/publishing-your-first-site"> | ||
| Publish your first Walrus Site using the `site-builder` tool. | ||
| <Card title="Getting Started" href="/docs/sites/getting-started/"> | ||
| Install the `site-builder` tool and deploy your first Walrus Site. | ||
| </Card> | ||
|
|
||
| <Card title="Set a SuiNS Name" href="/docs/sites/custom-domains/setting-a-suins-name"> | ||
| Setup SuiNS names for human-readable Walrus Sites domain names and portal browsing. | ||
| <Card title="Site Configuration" href="/docs/sites/configuration/"> | ||
| Configure your site's routing, headers, metadata, and deployment settings using `ws-resources.json` and `sites-config.yaml`. | ||
| </Card> | ||
|
|
||
|
|
||
| <Card title="Portals" href="/docs/sites/portals/"> | ||
| Learn how portals resolve and serve Walrus Sites to browsers, and how to run your own portal locally. | ||
| </Card> | ||
|
|
||
| <Card title="Custom Domains" href="/docs/sites/custom-domains/"> | ||
| Assign a SuiNS name to your site for a human-readable URL, or bring your own existing domain. | ||
| </Card> | ||
|
|
||
| <Card title="Linking" href="/docs/sites/linking/"> | ||
| Link to and from Walrus Sites, including how to give individual Sui objects their own dedicated pages. | ||
| </Card> | ||
|
|
||
| <Card title="CI/CD" href="/docs/sites/ci-cd"> | ||
| Automate deployments to Walrus Sites using GitHub Actions and other CI/CD pipelines. | ||
| </Card> | ||
|
|
||
| <Card title="Security" href="/docs/sites/security"> | ||
| Understand the security guarantees of Walrus Sites, site isolation, and how to handle sensitive data. | ||
| </Card> | ||
|
|
||
| <Card title="Known Restrictions" href="/docs/sites/known-restrictions"> | ||
| Review the current limitations of Walrus Sites, including restrictions on dynamic content, redirects, and backend support. | ||
| </Card> | ||
|
|
||
| <Card title="Troubleshooting" href="/docs/sites/troubleshooting"> | ||
| Find solutions to common issues encountered when publishing or accessing Walrus Sites. | ||
| </Card> | ||
|
|
||
| </Cards> | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,73 +1,105 @@ | ||
| --- | ||
| title: Introduction to Walrus Sites | ||
| description: "Introduction to Walrus Sites - decentralized websites using Sui and Walrus for hosting static web content." | ||
| keywords: ["walrus sites", "decentralized websites", "sui blockchain", "static sites", "web hosting", "nft websites", "suins", "site builder", "dapp"] | ||
| title: Walrus Sites Components | ||
| description: "An overview of the main components that make up a Walrus Site: Walrus blob storage, the Sui site object, the site-builder CLI, ws-resources.json, and portals." | ||
jon-mysten marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| keywords: ["walrus sites", "site-builder", "portal", "ws-resources", "sui object", "walrus blob", "suins", "static sites", "decentralized websites"] | ||
| --- | ||
|
|
||
| {/* https://linear.app/mysten-labs/issue/DOCS-662/sitesintroductioncomponents */} | ||
|
|
||
|
|
||
| *Walrus Sites* are "web"-sites that use Sui and Walrus as their underlying technology. They are a | ||
| prime example of how Walrus can be used to build new and exciting decentralized applications. Anyone | ||
| can build and deploy a Walrus Site and make it accessible to the world! Interestingly, this documentation | ||
| is itself available as a Walrus Site at https://docs.wal.app/docs/sites/introduction/components (if you | ||
| aren't there already). | ||
|
|
||
| At a high level, here are some of the most exciting features: | ||
|
|
||
| - Publishing a site does not require managing servers or complex configurations; just provide the | ||
| source files (produced by your favorite web framework), publish them to Walrus Sites using the | ||
| [`site-builder` tool](/docs/sites/introduction/technical-overview#the-site-builder), and you are done! | ||
| - Sites can be linked to from ordinary Sui objects. This feature enables, for example, creating an | ||
| NFT collection in which *every single NFT* has a *personalized website dedicated to it*. | ||
| - Walrus Sites are owned by addresses on Sui and can be exchanged, shared, and updated thanks to | ||
| Sui's flexible programming model. This means, among other things, that Walrus Sites can leverage | ||
| the [SuiNS](https://suins.io/) naming system to have human-readable names. No more messing around | ||
| with DNS! | ||
| - Thanks to Walrus's decentralization and extremely high data availability, there is no risk of | ||
| having your site wiped for any reason. | ||
| - Since they live on Walrus, these sites cannot have a backend in the traditional sense, and can | ||
| therefore be considered "static" sites. However, the developer can integrate with Sui-compatible | ||
| wallets and harness Sui's programmability to add backend functionality to Walrus Sites! | ||
|
|
||
| ## Show me | ||
|
|
||
| To give you a very high-level view of how Walrus Sites work, let's look at an example: A simple | ||
| NFT collection on Sui that has a frontend dApp to mint the NFTs hosted on Walrus Sites, and in | ||
| which *each NFT* has a *specific, personalized Walrus Site*. | ||
|
|
||
| You can check out the mint page at https://flatland.wal.app/. This site is served to your | ||
| browser through the Walrus Site *portal* https://wal.app. While the portal's operation is | ||
| explained in a [later section](/docs/sites/portals/deploy-locally), consider for now that there can be many portals (hosted | ||
| by whoever wants to have their own, and even on `localhost`). Further, the only function of the | ||
| portal is to retrieve the metadata (from Sui) and the resource files (from Walrus) that constitute | ||
| the site. | ||
|
|
||
| If you have a Sui wallet with some SUI, you can try and "mint a new Flatlander" from the site. This | ||
| creates an NFT from the collection and shows you two links: one to the explorer, and one to the | ||
| "Flatlander site". This latter site is a special Walrus Sites page that exists only for that NFT, | ||
| and has special characteristics (the background color, the image, ...) that are based on the | ||
| contents of the NFT. | ||
|
|
||
| The URL to this per-NFT site looks something like this: | ||
| `https://flatland.wal.app/0x811285f7bbbaad302e23a3467ed8b8e56324ab31294c27d7392dac649b215716`. | ||
| You'll notice that the domain remains `wal.app`, but the path is a long and random-looking | ||
| string. This string is actually the [hexadecimal](https://simple.wikipedia.org/wiki/Hexadecimal) | ||
| encoding of the object ID of the NFT, which is [0x811285f7b...][flatlander]. This path is unique to | ||
| each NFT and is used to fetch the metadata and resource files for its corresponding page. The page | ||
| is then rendered based on the characteristics of the NFT. | ||
|
|
||
| In summary: | ||
|
|
||
| - Walrus Sites are served through a portal; in this case, `https://wal.app`. There can be many | ||
| portals, and anyone can host one. | ||
| - The subdomain on the URL points to a specific object on Sui that allows the browser to fetch and | ||
| render the site resources. This pointer should be a SuiNS name, such as `flatland` in | ||
| `https://flatland.wal.app`. | ||
| - It is possible for each path to be mapped to a specific object on Sui that allows the browser to | ||
| fetch and render a page based on the characteristics of the NFT. | ||
|
|
||
| Curious to know how this magic is possible? Read the [technical overview](/docs/sites/introduction/technical-overview)! If you | ||
| just want to get started trying Walrus Sites out, check the [tutorial](/docs/sites). | ||
|
|
||
| [flatlander]: https://suiscan.xyz/mainnet/object/0x811285f7bbbaad302e23a3467ed8b8e56324ab31294c27d7392dac649b215716 | ||
| A Walrus Site is made up of 4 main components that work together: the site's resource files stored on Walrus, a [Sui object](https://docs.sui.io/guides/developer/objects/object-model) that indexes those resources, the [`site-builder` CLI](/docs/sites/getting-started/installing-the-site-builder) that publishes and updates the site, and a portal that serves the site to browsers. | ||
|
|
||
| ## Resource files on Walrus | ||
|
|
||
| Your site's static assets (HTML, CSS, JavaScript, images, fonts, and so on) are stored as blobs on Walrus. When you deploy a site, the `site-builder` uploads your build directory to Walrus by encoding multiple files into a [single quilt](/docs/system-overview/quilt) to reduce upload cost and improve upload speed. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. not always a build directory, depends on the tool - should reword for more general workflows
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. also, there should be some initial verbiage that introduces quilt rather than just indicating that it reduces upload cost and improves speed - something like "by encoding multiple files into a single storage entity called a quilt, a unique feature designed to reduce upload cost and improve upload speed." |
||
|
|
||
| Each file in the quilt is assigned a `QuiltPatchID`, which the Sui site object uses to locate and retrieve the file later. Because Walrus is a decentralized storage network, there is no single server that can take your content offline. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the latter portion should be moved to the section about the site object. in this section, its only relevant to know that each file is given a patchID |
||
|
|
||
| :::info | ||
| Blobs are stored for a fixed number of epochs. On Mainnet, each epoch lasts 14 days. On Testnet, each epoch lasts 1 day. The maximum storage duration is 53 epochs. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this feels random - is there a better place for data permanence information? |
||
| ::: | ||
|
|
||
| The trade-off of using quilts is that you cannot update a single file in isolation. If any file in your site changes, the entire quilt is re-uploaded on the next deploy. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this doesn't really matter to the user at this time - the site builder does this by default. i would remove this from this part |
||
|
|
||
| ## The Sui site object | ||
|
|
||
| Each Walrus Site corresponds to a single object on Sui, defined by the Move smart contract in the [`move/walrus_site`](https://github.com/MystenLabs/walrus-sites/tree/main/move/walrus_site) directory of the repository. At its core, a site object is a simple structure: | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. should we explain how this model differs from storing other data on Walrus? this might be confusing, since a walrus site = multiple blobs = quilt = single sui object, and other storage on Walrus is blob = object ? |
||
|
|
||
| ```move | ||
| struct Site has key, store { | ||
| id: UID, | ||
| name: String, | ||
| } | ||
| ``` | ||
|
|
||
| Each resource (file) in the site is attached to this object as a dynamic field of type `Resource`: | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would pick one term or the other - resource or file. switching between them is confusing |
||
|
|
||
| ```move | ||
| struct Resource has store, drop { | ||
| path: String, | ||
| blob_id: u256, | ||
| // ...headers and other metadata | ||
| } | ||
| ``` | ||
|
|
||
| The `path` field corresponds to the file's URL path (for example, `/index.html`), and `blob_id` is the Walrus identifier for the file's content. Together, the site object and its dynamic fields form an on-chain index that maps every URL path in your site to its content on Walrus. | ||
|
|
||
| Because the site object is a standard Sui object, it follows Sui's ownership model. The wallet that deployed the site owns the object and is the only wallet that can update or destroy it. You can also assign a [SuiNS](https://suins.io/) name to the object, giving your site a human-readable domain name. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "follows Sui's ownership model" doesn't mean anything to the user who knows nothing about Sui - this needs more context, less assumptions |
||
|
|
||
| ## The `site-builder` CLI | ||
|
|
||
| The `site-builder` is a Rust CLI tool that creates and manages Walrus Sites. It takes your site's build output directory as input and handles uploading files to Walrus and writing the on-chain index to Sui. | ||
|
|
||
| The primary command is [`deploy`](/docs/sites/getting-started/using-the-site-builder#deploy), which both publishes new sites and updates existing ones: | ||
|
|
||
| ```sh | ||
| site-builder deploy --epochs <NUMBER> <DIRECTORY> | ||
| ``` | ||
|
|
||
| When you run `deploy` for the first time, it publishes a new site and writes the resulting Sui object ID to the `object_id` field in `ws-resources.json`. On subsequent runs, `deploy` reads that object ID and updates the existing site instead of creating a new one. | ||
|
|
||
| Additionally, the `site-builder` requires a [`sites-config.yaml` configuration file](/docs/sites/getting-started/using-the-site-builder) that specifies the Sui package ID for the Walrus Sites contract and your network context. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this should be first, the config is a prereq to anyone running the deploy command |
||
|
|
||
| ## `ws-resources.json` | ||
|
|
||
| [`ws-resources.json`](/docs/sites/configuration/site-configuration) is a configuration file you place in your site's root directory. The `site-builder` reads it during deployment and uses it to control how your site is built and served. The file itself is not uploaded to Walrus and is not accessible to visitors. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "you place in your site's root directory" - technically it can be placed anywhere and specified with a flag, so maybe leave just this bit out |
||
|
|
||
| The file supports the following fields: | ||
|
|
||
| - **`object_id`:** The Sui object ID of your deployed site. The `site-builder` writes this automatically after the first deploy. If present, subsequent `deploy` calls update the existing site rather than publishing a new one. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. no bolding for in-line code per latest style guide
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. also, is a full list of the details needed here, or is a minimal example with brief definitions included as comments in the example suffice? |
||
| - [**`headers`:**](/docs/sites/configuration/specifying-http-headers) Custom HTTP response headers for specific resources. Useful for cache control, content type overrides, and security headers. | ||
| - [**`routes`:**](/docs/sites/configuration/setting-up-routing-rules) Client-side routing rules. Use this to support single-page application (SPA) frameworks such as React or Angular, where the app handles routing in the browser. Routes are defined as path patterns mapped to resource paths. | ||
| - [**`metadata`:**](/docs/sites/configuration/adding-metadata) Site metadata such as `site_name`, `description`, `image_url`, `project_url`, and `creator`. This information is stored in the Sui site object and displayed in wallets. | ||
| - **`ignore`:** A list of path patterns to exclude from deployment. Useful for keeping development files or secrets out of the published site. | ||
|
|
||
| A minimal example: | ||
|
|
||
| ```json | ||
| { | ||
| "object_id": "0x...", | ||
| "site_name": "My Site", | ||
| "routes": { | ||
| "/app/*": "/index.html" | ||
| }, | ||
| "metadata": { | ||
| "description": "A site built on Walrus.", | ||
| "link": "https://example.wal.app" | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| :::caution | ||
| Walrus Sites does not support dynamic redirects. Redirect plugins used in frameworks like Docusaurus resolve routes at the server level, which Walrus Sites does not have. Use the `routes` field in `ws-resources.json` to simulate client-side routing instead. | ||
| ::: | ||
|
|
||
| ## Portals | ||
|
|
||
| A [portal](/docs/sites/portals/mainnet-testnet) is the service that resolves and serves a Walrus Site to a visitor's browser. When a visitor navigates to a Walrus Site URL, the portal performs the following steps: | ||
jon-mysten marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| 1. Resolves the subdomain to a Sui object ID, either through a SuiNS name lookup or by decoding the Base36-encoded object ID directly from the subdomain. | ||
| 2. Reads the site object's dynamic fields from Sui to get the resource map. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. needs a crosslink to a resource on dynamic fields |
||
| 3. Fetches the requested resource's blob from Walrus using the `blob_id` from that map. | ||
| 4. Returns the blob content to the browser with the appropriate headers. | ||
|
Comment on lines
+98
to
+99
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. mentioning blobs here is confusing since before it was specified as a single quilt - should clarify/simplify |
||
|
|
||
| This process repeats for every resource the browser requests, such as linked CSS files, scripts, and images. | ||
|
|
||
| The public Mainnet portal operated by Mysten Labs is available at [https://wal.app](https://wal.app). It serves sites whose Sui objects have a SuiNS name configured. To access a site without a SuiNS name, use the Base36-encoded object ID as the subdomain, or use the `site-builder convert` command to find it. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the second sentence here reads a bit funny, I'd reword |
||
|
|
||
| Anyone can host their own portal. For setup instructions, see [Deploy a Local Portal](/docs/sites/portals/deploy-locally). | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use
instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah right i forgot you fixed the auto-genning stuff, ty !