diff --git a/docs/tutorials.mdx b/docs/tutorials.mdx
index 8149c111a..391d61525 100644
--- a/docs/tutorials.mdx
+++ b/docs/tutorials.mdx
@@ -117,4 +117,20 @@ These tutorials are intended for developers who are familiar with Tezos and want
   link="Start tutorial"
 />
 
+<TutorialCard
+  title="Implement a file archive with the DAL"
+  emoji="🗃️"
+  href="/tutorials/build-files-archive-with-dal"
+  description="Learn how to build a file archive with a Smart Rollup and the data availability layer"
+  link="Start tutorial"
+/>
+
+<TutorialCard
+  title="Join the DAL as a Weeklynet baker"
+  emoji="🍞"
+  href="/tutorials/join-dal-baker"
+  description="Learn how to participate to the DAL as a baker"
+  link="Start tutorial"
+/>
+
 </TutorialCardContainer>
diff --git a/docs/tutorials/build-files-archive-with-dal.mdx b/docs/tutorials/build-files-archive-with-dal.mdx
new file mode 100644
index 000000000..121a98a0f
--- /dev/null
+++ b/docs/tutorials/build-files-archive-with-dal.mdx
@@ -0,0 +1,153 @@
+---
+title: Implementing a file archive with the DAL and a Smart Rollup
+authors: 'Tezos Core Developers'
+last_update:
+  date: 17 January 2024
+---
+
+import LucidDiagram from '@site/src/components/LucidDiagram';
+
+:::note Experimental
+The data availability layer is an experimental feature that is not yet available on Tezos Mainnet.
+The way the DAL works may change significantly before it is generally available.
+:::
+
+The data availability layer (DAL) is a companion peer-to-peer network for the Tezos blockchain, designed to provide additional data bandwidth to Smart Rollups.
+It allows users to share large amounts of data in a way that is decentralized and permissionless, because anyone can join the network and post and read data on it.
+
+In this tutorial, you will set up a file archive that stores and retrieves files with the DAL.
+You will learn:
+
+- How data is organized and shared with the DAL and the reveal data channel
+- How to read data from the DAL in a Smart Rollup
+- How to host a DAL node
+- How to publish data and files with the DAL
+
+Because the DAL is not yet available on Tezos Mainnet, this tutorial uses the [Weeklynet test network](https://teztnets.com/weeklynet-about), which runs on a newer version of the protocol that includes the DAL.
+
+See these links for more information about the DAL:
+
+- For technical information about how the DAL works, see [Data Availability Layer](https://tezos.gitlab.io/shell/dal.html) in the Octez documentation.
+- For more information about the approach for the DAL, see [The Rollup Booster: A Data-Availability Layer for Tezos](https://research-development.nomadic-labs.com/data-availability-layer-tezos.html).
+
+## Prerequisites
+
+This article assumes some familiarity with Smart Rollups.
+If you are new to Smart Rollups, see the tutorial [Deploy a Smart Rollup](./smart-rollup).
+
+### Set up a Weeklynet environment and account
+
+Because Weeklynet requires a specific version of the Octez suite, you can't use most wallet applications and installations of the Octez suite with it.
+Instead, you must set up an environment with a specific version of the Octez suite and use it to create and fund an account.
+Note that Weeklynet is reset every Wednesday, so you must recreate your environment and account after the network resets.
+
+The easiest way to do this is to use the Docker image that is generated each time Weeklynet is reset and recreated.
+As another option, you can build the specific version of the Octez suite locally.
+For instructions, see the Weeklynet page at https://teztnets.com/weeklynet-about.
+
+To set up an environment and account in a Docker container, follow these steps:
+
+1. From the [Weeklynet](https://teztnets.com/weeklynet-about) page, find the Docker command to create a container from the correct Docker image, as in this example:
+
+   ```bash
+   docker run -it --entrypoint=/bin/sh tezos/tezos:master_7f3bfc90_20240116181914
+   ```
+
+   The image tag in this command changes each time the network is reset.
+
+1. Copy the URL of the public RPC endpoint for Weeklynet, such as `https://rpc.weeklynet-2024-01-17.teztnets.com`.
+This endpoint also changes each time the network is reset.
+
+1. For convenience, you may want to set this endpoint as the value of the `ENDPOINT` environment variable.
+
+1. In the container, initialize the Octez client with that endpoint, such as this example:
+
+   ```bash
+   octez-client -E https://rpc.weeklynet-2024-01-17.teztnets.com config init
+   ```
+
+1. Create an account with the command `octez-client gen keys $MY_ACCOUNT`, where `$MY_ACCOUNT` is an alias for your account.
+
+1. Get the public key hash of the new account by running the command `octez-client show address $MY_ACCOUNT`.
+
+1. From the [Weeklynet](https://teztnets.com/weeklynet-about) page, open the Weeklynet faucet and send some tez to the account.
+
+Now you can use this account to deploy Smart Rollups.
+
+### Install Rust
+
+To run this tutorial, install Rust by running the following command.
+The application in this tutorial uses Rust because of its support for WebAssembly (WASM), the language that Smart Rollups use to communicate.
+Rollups can use any language that has WASM compilation support.
+
+```bash
+curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
+```
+
+Then, add WASM as a compilation target for Rust by running this command:
+
+```bash
+rustup target add wasm32-unknown-unknown
+```
+
+You can see other ways of installing Rust at https://www.rust-lang.org.
+
+## Why the DAL?
+
+The DAL has earned the nickname "Rollup Booster" from its ability to address
+the last bottleneck Smart Rollups developers could not overcome without
+sacrificing decentralization: block space. Smart Rollups offload
+*computation* from layer 1, but the transactions that they process still need to
+originate from somewhere.
+
+By default, that "somewhere" is the layer 1 blocks, yet the size of a Tezos
+block is limited to around 500KBytes. In this model, while Smart Rollups do not
+compete for layer 1 gas anymore, they still compete for block space.
+
+{/* Is this info about the reveal data channel needed here? */}
+Additionally, a Smart Rollup can fetch data from an additional source called the
+reveal data channel, which allows them to retrieve arbitrary data.
+The reveal channel is a powerful way to share data, because it allows a Smart Rollup
+operator to post hashes instead of full data files on layer 1. But it is a
+double-edged sword, because nothing enforces the availability of the data in the
+first place. [Solutions exist to address this
+challenge](https://research-development.nomadic-labs.com/introducing-data-availability-committees.html),
+but they are purely off-chain ones, coming with no guarantee from layer 1.
+
+The DAL allows third parties to publish data and have bakers attest that the data is available.
+When enough bakers have attested that the data is available, Smart Rollups can retrieve the data without the need for additional trusted third-parties.
+
+## How the DAL works
+
+In this tutorial, you create a file archive application that allows clients to upload data to the DAL.
+You also create a Smart Rollup that listens to the DAL and responds to that data.
+
+The DAL works like this:
+
+1. Users post data to a DAL node.
+1. The DAL node returns a certificate.
+This certificate includes a commitment that the data is available and a proof of the data.
+1. Users post the certificate to layer 1 via the Octez client, which is much cheaper than posting the complete data.
+1. When the certificate is confirmed in a block, layer 1 splits the data into shards and assigns those shards to bakers, who verify that the data is available.
+1. Bakers verify that the data is available and attest that the data is available in their usual block attestations to layer 1.
+They have a certain number of blocks to do so, known as the _attestation lag_, and if they don't by the end of this period, the certificate is considered bogus and the related data is dropped.
+1. Other DAL nodes get the data from the initial DAL node through the peer-to-peer network.
+1. The Smart Rollup node monitors the blocks and when it sees attested DAL data, it connects to a DAL node to request the data.
+1. The Smart Rollup node stores the data in its durable storage, addressed by its hash.
+Smart Rollups must store the data because it is available on the DAL for only a short time.
+1. Users who know the hash of the data can download it from the Smart Rollup node.
+
+The overall workflow is summarized in the following figure:
+
+<LucidDiagram width="640px" height="480px" src="https://lucid.app/documents/embedded/cc422278-7319-4a2f-858a-a7b72e1ea3a6" id="ljs6hoejIr1H" />
+
+There are many steps in the DAL process, but the most complicated parts (storing and sharing data) are handled automatically by the various daemons in the Octez suite.
+
+:::note The Smart Rollup installer does not support the DAL
+As of today, the Smart Rollup installer does not support the DAL as a
+data availability solution. This means we will need to rely on the reveal
+channel to initialize our Smart Rollup correctly (which is not ideal for a
+decentralized file archive).
+:::
+
+When your environment is ready, get started by going to [Part 1: Getting the DAL parameters](./build-files-archive-with-dal/get-dal-params).
diff --git a/docs/tutorials/build-files-archive-with-dal/get-dal-params.mdx b/docs/tutorials/build-files-archive-with-dal/get-dal-params.mdx
new file mode 100644
index 000000000..03ea7292f
--- /dev/null
+++ b/docs/tutorials/build-files-archive-with-dal/get-dal-params.mdx
@@ -0,0 +1,173 @@
+---
+title: "Part 1: Getting the DAL parameters"
+authors: 'Tezos Core Developers'
+last_update:
+  date: 17 January 2024
+---
+
+import LucidDiagram from '@site/src/components/LucidDiagram';
+
+The data availability layer stores information about the available data in layer 1 blocks.
+Each block has several byte-vectors called _slots_, each with a maximum size.
+DAL users can add information about the available data as _pages_ in these slots, as shown in this figure:
+
+<LucidDiagram width="640px" height="480px" src="https://lucid.app/documents/embedded/46fa8412-8443-4491-82f6-305aafaf85f2" id="Hxs62lrO0C4d" />
+
+The data in a slot is broken into pages to ensure that each piece of data can fit in a single Tezos operation.
+This data must fit in a single operation to allow the Smart Rollup refutation game to work, in which every execution step of the Smart Rollup must be provable to layer 1.
+{/* TODO link to Smart Rollup topic for more info on the refutation game */}
+
+When clients add data, they must specify which slot to add it to.
+Note that because the DAL is permissionless, clients may try to add data to the same slot in the same block.
+In this case, the first operation in the block takes precedence, which leaves the baker that creates the block in control of which data makes it into the block.
+Other operations that try to add data to the same slot fail.
+
+The number and size of these slots can change.
+Different networks can have different DAL parameters.
+Future changes to the protocol may allow the DAL to resize dynamically based on usage.
+
+Therefore, clients must get information about the DAL before sending data to it.
+In these steps, you set up a simple Smart Rollup to get the current DAL parameters and print them to the log.
+
+## Prerequisites
+
+Before you begin, make sure that you have installed the prerequisites and set up an environment and an account as described in [Implementing a File Archive with the DAL and a Smart Rollup](../build-files-archive-with-dal).
+
+## Fetching the DAL parameters in a kernel
+
+To get the DAL parameters, you can use built-in functions in the Tezos [Rust SDK](https://crates.io/crates/tezos-smart-rollup).
+
+1. In a folder for your project, create a file named `Cargo.toml` with this code:
+
+   ```toml
+   [package]
+   name = "files_archive"
+   version = "0.1.0"
+   edition = "2021"
+
+   [lib]
+   crate-type = ["cdylib", "lib"]
+
+   [dependencies]
+   tezos-smart-rollup = { version = "0.2.2", features = [ "proto-alpha" ] }
+   ```
+
+   As a reminder, the kernel of a Smart Rollup is a WASM program.
+   The `proto-alpha` feature is necessary to get access to the functions specific to the DAL.
+
+1. Create a file named `src/lib.rs` to be the kernel.
+
+1. In the `src/lib.rs` file, add this code:
+
+   ```rust
+   use tezos_smart_rollup::{kernel_entry, prelude::*};
+
+   pub fn entry<R: Runtime>(host: &mut R) {
+       let param = host.reveal_dal_parameters();
+       debug_msg!(host, "{:?}\n", param);
+   }
+
+   kernel_entry!(entry);
+   ```
+
+   This function gets the DAL parameters of the currently connected network and prints them to the log.
+
+1. Build the kernel:
+
+   ```bash
+   cargo build --release --target wasm32-unknown-unknown
+   cp target/wasm32-unknown-unknown/release/files_archive.wasm .
+   ```
+
+1. Get the installer kernel:
+
+   ```bash
+   cargo install tezos-smart-rollup-installer
+   export PATH="${HOME}/.local/bin:${PATH}"
+   smart-rollup-installer get-reveal-installer \
+       -P _rollup_node/wasm_2_0_0 \
+       -u files_archive.wasm \
+       -o installer.hex
+   ```
+
+Now the Smart Rollup is ready to deploy.
+
+## Deploying the Smart Rollup and starting a node
+
+Follow these steps to deploy the Smart Rollup to Weeklynet and start a node:
+
+1. Run this command to deploy the Smart Rollup, replacing `$MY_ACCOUNT` with your account alias and `$ENDPOINT` with the RPC endpoint:
+
+   ```bash
+   octez-client --endpoint ${ENDPOINT} \
+       originate smart rollup files_archive from ${MY_ACCOUNT} \
+       of kind wasm_2_0_0 of type unit with kernel "$(cat installer.hex)" \
+       --burn-cap 2.0 --force
+   ```
+
+1. Start the node with this command:
+
+   ```bash
+   octez-smart-rollup-node --endpoint ${ENDPOINT} \
+       run observer for files_archive with operators \
+       --data-dir ./_rollup_node --log-kernel-debug
+   ```
+
+   For simplicity, this command runs the Smart Rollup in observer mode, which does not require a stake of 10,000 tez to publish commitments.
+
+1. Open a new terminal window and run this command to watch the node's log:
+
+   ```bash
+   tail -F _rollup_node/kernel.log
+   ```
+
+The log prints the current DAL parameters, as in this example:
+
+```
+RollupDalParameters { number_of_slots: 32, attestation_lag: 4, slot_size: 65536, page_size: 4096 }
+RollupDalParameters { number_of_slots: 32, attestation_lag: 4, slot_size: 65536, page_size: 4096 }
+RollupDalParameters { number_of_slots: 32, attestation_lag: 4, slot_size: 65536, page_size: 4096 }
+RollupDalParameters { number_of_slots: 32, attestation_lag: 4, slot_size: 65536, page_size: 4096 }
+RollupDalParameters { number_of_slots: 32, attestation_lag: 4, slot_size: 65536, page_size: 4096 }
+```
+
+These parameters are:
+
+- `number_of_slots`: The number of slots in each block
+- `slot_size`: The size of each slot in bytes
+- `page_size`: The size of each page in bytes
+- `attestation_lag`: The number of subsequent blocks in which bakers can attest that the data is available; if enough attestations are available by the time this number of blocks have been created, the data becomes available to Smart Rollups
+
+## Setting up a deployment script
+
+In later parts of this tutorial, you will update and redeploy the Smart Rollup multiple times.
+To simplify the process, you can use this script.
+To use it, pass the alias of your account in the Octez client:
+
+```bash
+#!/usr/bin/bash
+
+alias="${1}"
+
+set -e
+
+cargo build --release --target wasm32-unknown-unknown
+
+rm -rf _rollup_node
+
+cp target/wasm32-unknown-unknown/release/files_archive.wasm .
+
+smart-rollup-installer get-reveal-installer -P _rollup_node/wasm_2_0_0 \
+  -u files_archive.wasm -o installer.hex
+
+octez-client --endpoint ${ENDPOINT} \
+  originate smart rollup files_archive from "${alias}" of kind wasm_2_0_0 \
+  of type unit with kernel "$(cat installer.hex)" --burn-cap 2.0 --force
+
+octez-smart-rollup-node --endpoint ${ENDPOINT} \
+  run observer for files_archive with operators --data-dir _rollup_node \
+  --dal-node http://localhost:10732 --log-kernel-debug
+```
+
+In the next section, you will get information about the state of slots in the DAL.
+See [Part 2: Getting slot information](./get-slot-info).
diff --git a/docs/tutorials/build-files-archive-with-dal/get-slot-info.mdx b/docs/tutorials/build-files-archive-with-dal/get-slot-info.mdx
new file mode 100644
index 000000000..f8c893c68
--- /dev/null
+++ b/docs/tutorials/build-files-archive-with-dal/get-slot-info.mdx
@@ -0,0 +1,138 @@
+---
+title: "Part 2: Getting slot information"
+authors: 'Tezos Core Developers'
+last_update:
+  date: 17 January 2024
+---
+
+When clients send data to the DAL, they must choose which slot to put it in.
+This can cause conflicts, because only one client can write data to a given slot in a single block.
+If more than one client tries to write to the same slot and a baker includes those operations in the same block, only the first operation in the block succeeds in writing data to the slot.
+The other operations fail and the clients must re-submit the data to be included in a future block.
+
+For this reason, clients should check the status of slots to avoid conflicts.
+For example, slots 0, 30, and 31 are often used for regression tests.
+
+To see which slots are in use, you can use the Explorus indexer at https://explorus.io/dal.
+For example, this screenshot shows that slots 10 and 25 are in use:
+
+![The Explorus indexer, showing the slots that are in use in each block](/img/tutorials/dal-explorus-slots.png)
+
+You can also see the state of the DAL slots by running a DAL node.
+To reduce the amount of data that they have to manage, DAL nodes can subscribe to certain slots and ignore the data in others.
+Similarly, the protocol assigns bakers to monitor certain slots.
+
+## Starting a DAL node
+
+To run a DAL node, use the Octez `octez-dal-node` command and pass the slots to monitor in the `--producer-profiles` argument.
+
+Run this command to start a DAL node and monitor slot 0:
+
+```bash
+octez-dal-node run --endpoint ${ENDPOINT} \
+    --producer-profiles=0 --data-dir _dal_node
+```
+
+## Accessing the slot data from a Smart Rollup
+
+Follow these steps to update the Smart Rollup to access information about slot 0:
+
+1. Update the `src/lib.rs` file to have this code:
+
+   ```rust
+   use tezos_smart_rollup::{host::RuntimeError, kernel_entry, prelude::*};
+   use tezos_smart_rollup_host::dal_parameters::RollupDalParameters;
+
+   pub fn run<R: Runtime>(
+       host: &mut R,
+       param: &RollupDalParameters,
+       slot_index: u8,
+   ) -> Result<(), RuntimeError> {
+       let sol = host.read_input()?.unwrap();
+
+       let target_level = sol.level as usize - param.attestation_lag as usize;
+
+       let mut buffer = vec![0u8; param.page_size as usize];
+
+       let bytes_read = host.reveal_dal_page(target_level as i32, slot_index, 0, &mut buffer)?;
+
+       if 0 < bytes_read {
+           debug_msg!(
+               host,
+               "Attested slot at index {} for level {}: {:?}\n",
+               slot_index,
+               target_level,
+               &buffer.as_slice()[0..10]
+           );
+       } else {
+           debug_msg!(
+               host,
+               "No attested slot at index {} for level {}\n",
+               slot_index,
+               target_level
+           );
+       }
+
+       Ok(())
+   }
+
+   pub fn entry<R: Runtime>(host: &mut R) {
+       let param = host.reveal_dal_parameters();
+       debug_msg!(host, "{:?}\n", param);
+
+       match run(host, &param, 0) {
+           Ok(()) => debug_msg!(host, "See you in the next level\n"),
+           Err(_) => debug_msg!(host, "Something went wrong for some reasons"),
+       }
+   }
+
+   kernel_entry!(entry);
+   ```
+
+   The key change is the addition of the function `run`.
+   Using this function allows the code to use the `?` operator of Rust by using a function that returns a `Result` type.
+
+   The `run` function proceeds as follows:
+
+      1. First, it uses the DAL parameters to know the first level where a slot might be used.
+      It subtracts the attestation lag from the current level, which it gets from the Smart Rollup inbox; the result is the most recent block that may have attested data in it.
+      1. It allocates `Vec<u8>` buffer of the current page size.
+      1. It attempts to fill the buffer with the `read_dal_page` function provided
+      by the SDK.
+      1. It checks the value returned by the function, which is the number of bytes
+      read.
+      Zero bytes mean that the slot has no attested data in it.
+      Otherwise, it is necessarily the size of the page, because that's the size of the buffer.
+
+1. Update the `Cargo.toml` file to add this dependency at the end:
+
+   ```toml
+   tezos-smart-rollup-host = { version = "0.2.2", features = [ "proto-alpha" ] }
+   ```
+
+1. Run the commands to build and deploy the Smart Rollup and start the node.
+You can use the script in [Part 1: Getting the DAL parameters](./get-dal-params) to simplify the process.
+
+1. In another terminal window, view the log with the command `tail -F _rollup_node/kernel.log`.
+
+The log shows information about slot 0, as in this example:
+
+```
+RollupDalParameters { number_of_slots: 32, attestation_lag: 4, slot_size: 65536, page_size: 4096 }
+No attested slot at index 0 for level 56875
+See you in the next level
+RollupDalParameters { number_of_slots: 32, attestation_lag: 4, slot_size: 65536, page_size: 4096 }
+Attested slot at index 0 for level 56876: [16, 0, 0, 2, 89, 87, 0, 0, 0, 0]
+See you in the next level
+RollupDalParameters { number_of_slots: 32, attestation_lag: 4, slot_size: 65536, page_size: 4096 }
+No attested slot at index 0 for level 56877
+See you in the next level
+```
+
+For the first 4 Tezos blocks produced after the origination of the Smart Rollup, the kernel will report that no slot has been attested for the targeted level, _even if Explorus states the opposite_.
+This is because, as of January, 2024, a Smart Rollup cannot fetch the content of a slot published before it is originated.
+This is why you must wait for 4 blocks before seeing slot page contents being
+logged.
+
+Now that you can see the state of the slots, you can find an unused slot and publish data to it.
+When you are ready, continue to [Part 3: Publishing on the DAL](./publishing-on-the-dal).
diff --git a/docs/tutorials/build-files-archive-with-dal/publishing-on-the-dal.mdx b/docs/tutorials/build-files-archive-with-dal/publishing-on-the-dal.mdx
new file mode 100644
index 000000000..0eca70dd1
--- /dev/null
+++ b/docs/tutorials/build-files-archive-with-dal/publishing-on-the-dal.mdx
@@ -0,0 +1,141 @@
+---
+title: "Part 3: Publishing on the DAL"
+authors: 'Tezos Core Developers'
+last_update:
+  date: 17 January 2024
+---
+
+Now that you can get information about the DAL, the next step is to publish data to it and verify that the kernel can access it.
+
+:::note Planning ahead
+Before trying to run the code yourself, look at [Explorus](https://explorus.io/dal) and choose a slot that is not currently being used.
+:::
+
+The examples in this tutorial use slot 10.
+
+## Switching slots
+
+When you have selected a slot that does not appear to be in use, follow these steps to restart the Smart Rollup and DAL node:
+
+1. Stop the DAL node and restart it with a new `--producer-profiles` argument.
+For example, this command uses slot 10:
+
+   ```bash
+   octez-dal-node run --endpoint ${ENDPOINT} \
+       --producer-profiles=10 --data-dir _dal_node
+   ```
+
+1. Update the kernel to monitor that slot by updating this line:
+
+   ```rust
+   match run(host, &param, 0) {
+   ```
+
+   For example, to monitor slot 10, change the 0 to a 10, as in this code:
+
+   ```rust
+   match run(host, &param, 10) {
+   ```
+
+1. Run the commands to build and deploy the Smart Rollup and start the node.
+You can use the script in [Part 1: Getting the DAL parameters](./get-dal-params) to simplify the process.
+
+## Publishing messages
+
+The DAL node provides an RPC endpoint for clients to send data to be added to a slot: `POST /slot`, whose body is the contents of the slot.
+
+1. Run this command to publish a message to the DAL:
+
+   ```bash
+   curl localhost:10732/slot --data '"Hello, world!"' -H 'Content-Type: application/json'
+   ```
+
+   This command assumes that you have not changed the default RPC server address.
+
+   The command returns the certificate from the DAL node, which looks like this example:
+
+   ```json
+   {
+     "commitment": "sh1u3tr3YKPDYUp2wWKCfmV5KZb82FREhv8GtDeR3EJccsBerWGwJYKufsDNH8rk4XqGrXdooZ",
+     "commitment_proof":"8229c63b8e858d9a96321c80a204756020dd13243621c11bec61f182a23714cf6e0985675fff45f1164657ad0c7b9418"
+   }
+   ```
+
+   Note that the value of the message is in double quotes because it must be a valid JSON string, as hinted by the `Content-Type` header.
+
+1. Using the values of the commitment and proof from the previous command, post the certificate to layer 1 with this command:
+
+   ```bash
+   commitment="sh1u3tr3YKPDYUp2wWKCfmV5KZb82FREhv8GtDeR3EJccsBerWGwJYKufsDNH8rk4XqGrXdooZ"
+   proof="8229c63b8e858d9a96321c80a204756020dd13243621c11bec61f182a23714cf6e0985675fff45f1164657ad0c7b9418"
+   octez-client --endpoint ${ENDPOINT} \
+       publish dal commitment "${commitment}" from ${MY_ACCOUNT} for slot 10 \
+       with proof "${proof}"
+   ```
+
+   After 4 blocks, you should see a message in the kernel log that looks like this:
+
+   ```
+   RollupDalParameters { number_of_slots: 32, attestation_lag: 4, slot_size: 65536, page_size: 4096 }
+   Attested slot at index 10 for level 57293: [72, 101, 108, 108, 111, 44, 32, 119, 111, 114]
+   See you in the next level
+   ```
+
+   You can verify your message by converting the bytes in the message back to the first 10 characters of the string "Hello, World!"
+
+   If you see a message that says "A slot header for this slot was already proposed," another transaction tried to write to that slot in the same block, so you must try again.
+
+   If you don't see information about the attested slot, check the page at https://explorus.io/dal.
+   If that page shows red (unattested) slots, it's possible that the attesters for the network are offline.
+
+## Publishing files
+
+You can also send raw bytes to the DAL node with the header `Content-Type: application/octet-stream`.
+In this case, you must prefix the data with its size due to limitations of the DAL.
+
+1. Install the `jq` and `xxd` programs.
+
+1. Create a file named `upload_file.sh` and add this code:
+
+   ```bash
+   #!/usr/bin/bash
+
+   path="${1}"
+   alias="${2}"
+   index="${3}"
+
+   target="$(mktemp)"
+   echo "storing temporary file at ${target}"
+   file_size="$(cat "${path}" | wc -c)"
+   slot_size_bin="$(printf "%08x" "${file_size}")"
+   slot_contents="$(cat ${path} | xxd -p)"
+
+   echo -n "${slot_size_bin}${slot_contents}" | xxd -p -r > "${target}"
+
+   certificate="$(curl localhost:10732/slot --data-binary "@${target}" -H 'Content-Type: application/octet-stream')"
+
+   echo "${certificate}"
+
+   commitment="$(echo -n ${certificate} | jq '.commitment' -r)"
+   proof="$(echo -n ${certificate} | jq '.commitment_proof' -r)"
+
+   octez-client --endpoint ${ENDPOINT} \
+       publish dal commitment "${commitment}" from "${alias}" \
+       for slot "${index}" with proof "${proof}"
+
+   rm "${target}"
+   ```
+
+   The script accepts three arguments: the file to send, the account alias to use and the slot index to use.
+   This script also assumes that the `PATH` and `ENDPOINT` environment variables are correctly set.
+   For example:
+
+   ```bash
+   ./upload_file.sh myFile.txt $MY_ACCOUNT 10
+   ```
+
+   Again, by inspecting the kernel logs, you should be able to see that the file that you wanted to publish is indeed the one fetched by the Smart Rollup.
+
+Now you can publish data to the DAL and use it in a Smart Rollup.
+In the next section, you write to and retrieve the entire slot.
+When you are ready, go to [Part 4: Using the entire slot](./using-full-slot).
diff --git a/docs/tutorials/build-files-archive-with-dal/using-full-slot.mdx b/docs/tutorials/build-files-archive-with-dal/using-full-slot.mdx
new file mode 100644
index 000000000..6ee53c95b
--- /dev/null
+++ b/docs/tutorials/build-files-archive-with-dal/using-full-slot.mdx
@@ -0,0 +1,146 @@
+---
+title: "Part 4: Using the entire slot"
+authors: 'Tezos Core Developers'
+last_update:
+  date: 18 January 2024
+---
+
+In some cases, you may want to retrieve the entire contents of a slot.
+For example, it can be convenient to get the entire slot because it has a fixed size, while the data in the slot may be smaller and padded to fit the slot.
+
+## Fetching and storing the full slot
+
+Retrieving the full slot is similar to retrieving any data from the slot.
+In this case, you change the kernel to retrieve data of the exact size of the slot.
+
+1. Update the `run` function in the `lib/rs` file to this code:
+
+   ```rust
+   pub fn run<R: Runtime>(
+       host: &mut R,
+       param: &RollupDalParameters,
+       slot_index: u8,
+   ) -> Result<(), RuntimeError> {
+       // Reading one message from the shared inbox is always safe,
+       // because the shared inbox contains at least 3 messages per
+       // Tezos block.
+       let sol = host.read_input()?.unwrap();
+
+       let target_level = sol.level as usize - param.attestation_lag as usize;
+
+       let mut buffer = vec![0u8; param.slot_size as usize];
+
+       let bytes_read = host.reveal_dal_page(target_level as i32, slot_index, 0, &mut buffer)?;
+
+       if bytes_read == 0 {
+           debug_msg!(
+               host,
+               "No attested slot at index {} for level {}\n",
+               slot_index,
+               target_level
+           );
+
+           return Ok(());
+       }
+
+       debug_msg!(
+           host,
+           "Attested slot at index {} for level {}\n",
+           slot_index,
+           target_level
+       );
+
+       let num_pages = param.slot_size / param.page_size;
+
+       for page_index in 1..num_pages {
+           let _result = host.reveal_dal_page(
+               target_level as i32,
+               slot_index,
+               page_index.try_into().unwrap(),
+               &mut buffer[page_index as usize * (param.page_size as usize)
+                   ..(page_index as usize + 1) * (param.page_size as usize)],
+           );
+       }
+
+       let hash = blake2b::digest(&buffer, 32).unwrap();
+       let key = hex::encode(hash);
+       let path = OwnedPath::try_from(format!("/{}", key)).unwrap();
+
+       debug_msg!(host, "Saving slot under `{}'\n", path);
+
+       let () = host.store_write_all(&path, &buffer)?;
+
+       Ok(())
+   }
+   ```
+
+   Now the `run` function works like this:
+
+      1. It allocates a buffer of the size of a slot, not a size of a page.
+      1. It tries to fetch the contents of the first page.
+      If 0 bytes are written by `reveal_dal_page`, the targeted slot has not been
+   attested for this block.
+      1. If the targeted slot has been attested, the function reads as many pages as necessary to get the full slot data.
+      1. It stores the data in the durable storage, using the Blake2B hash (encoded in hexadecimal) as its key.
+
+1. Add these `use` statements to the beginning of the file:
+
+   ```rust
+   use tezos_crypto_rs::blake2b;
+   use tezos_smart_rollup::storage::path::OwnedPath;
+   ```
+
+   These dependencies use `tezos_crypto_rs` for hashing, and `hex` for encoding.
+
+1. Add the matching dependencies to the `Cargo.toml` file:
+
+   ```toml
+   tezos_crypto_rs = { version = "0.5.2", default-features = false }
+   hex = "0.4.3"
+   ```
+
+   Adding `default-features = false` for `tezos_crypto_rs` is necessary for the crate to be compatible with Smart Rollups.
+
+1. Deploy the Smart Rollup again, publish a file as you did in the previous section, and wait for enough levels to pass.
+The Smart Rollup log shows the hash of the data, as in this example:
+
+   ```
+   RollupDalParameters { number_of_slots: 32, attestation_lag: 4, slot_size: 65536, page_size: 4096 }
+   Attested slot at index 10 for level 15482
+   Saving slot under `/6a578d1e6746d29243ff81923bcea6375e9344d719ca118e14cd9f3d3b00cd96'
+   See you in the next level
+   ```
+
+1. Get the data from the slot by passing the hash, as in this example:
+
+   ```bash
+   hash=6a578d1e6746d29243ff81923bcea6375e9344d719ca118e14cd9f3d3b00cd96
+   curl "http://localhost:8932/global/block/head/durable/wasm_2_0_0/value?key=/${hash}" \
+       -H 'Content-Type: application/octet-stream' \
+       -o slot.bin
+   ```
+
+1. Convert the contents of the slot to text by running this command:
+
+   ```bash
+   xxd -r -p slot.bin
+   ```
+
+   The console shows your message in text, such as "Hi! This is a message to go on the DAL."
+
+:::note Why `diff` won't work
+You cannot use `diff` to ensure that the file you originally published and the one that you downloaded from the rollup node are equal.
+Indeed, they are not: because the size of a slot is fixed, the DAL node pads the value it receives from `POST /slot` in order to ensure that it has the correct slot size.
+:::
+
+## Next steps
+
+Now you know how to send files to the DAL and use a Smart Rollup to store the data.
+
+From there, the sky's the limit.
+You can implement many other features, such as:
+
+- Handling more than one file per level
+- Having file publishers pay for the storage that they are using in layer 2 by allowing them to deposit tez to the Smart Rollup and sign the files they publish
+- Building a frontend to visualize the files in the archive
+- Providing the original size of the file by modifying the script to prefix the file with its size
diff --git a/docs/tutorials/join-dal-baker.md b/docs/tutorials/join-dal-baker.md
new file mode 100644
index 000000000..5894d3070
--- /dev/null
+++ b/docs/tutorials/join-dal-baker.md
@@ -0,0 +1,26 @@
+# How to join the Tezos DAL as a baker, in 5 steps
+
+Tezos' [Data-Availability Layer](https://tezos.gitlab.io/shell/dal.html) (DAL for short), is an experimental feature which is, at the time of writing, not available on Tezos Mainnet but planned to be proposed in a protocol amendment in the near future.
+
+The DAL is a key component for the scalability of Tezos. In a nutshell, the DAL is about increasing the data bandwidth available for Tezos Smart Rollups thanks to a new parallel P2P network on which rollups could connect to fetch inputs without compromising their security.
+
+In order for the DAL to be as secure as the Tezos Layer 1 itself, bakers need to play a very important role in it. Currently, bakers on the L1 network are not only responsible for producing blocks but also for attesting that blocks are published on the L1 network. They are rewarded for this contribution through protocol incentives. Similarly, the role of bakers in the DAL would be to attest the publication of data on the DAL's P2P network. They would in turn be rewarded for this through (potentially different) protocol incentives.
+
+Given that setting up a new P2P network with several hundred active participants may take some time, the first proposed version of the DAL for Tezos Mainnet will not provide any participation incentives. This will let plenty of time for bakers to join the DAL network without risking any reward loss, ensuring a smooth transition.
+
+This incentive-free version of the DAL is already available on the Weeklynet test network. In this tutorial you will learn how to join Weeklynet as a baker and attest the publication of data on the DAL network.
+
+:::warning
+This tutorial uses a very simple setup running all required daemons on the same machine. In a production environment, we advise against running a DAL attester node under the same IP address than a baker's node because the DAL node may leak the IP address and ease DOS attacks on the baker. See also [the DAL documentation page on baking](https://tezos.gitlab.io/shell/dal_bakers.html).
+:::
+
+:::warning
+The UX of the DAL components will be subject to changes with the feedback from the testers following this tutorial, so this tutorial will be updated accordingly. Feel free to file issues if it's not up-to-date.
+:::
+
+- [Step 1: get a Weeklynet-compatible Octez version](./join-dal-baker/get-octez)
+- [Step 2: run an Octez node on Weeklynet](./join-dal-baker/run-node)
+- [Step 3: setting up a baker account on Weeklynet](./join-dal-baker/prepare-account)
+- [Step 4: run an Octez DAL node on Weeklynet](./join-dal-baker/run-dal-node)
+- [Step 5: run an Octez baking daemon on Weeklynet](./join-dal-baker/run-baker)
+- [Conclusion](./join-dal-baker/conclusion)
diff --git a/docs/tutorials/join-dal-baker/conclusion.md b/docs/tutorials/join-dal-baker/conclusion.md
new file mode 100644
index 000000000..58c297504
--- /dev/null
+++ b/docs/tutorials/join-dal-baker/conclusion.md
@@ -0,0 +1,3 @@
+# Conclusion
+
+In this tutorial we have gone through all the steps needed to participate in the Weeklynet test network as a baker and DAL attester. We could further improve the setup by defining system services so that the daemons are automatically launched when the machine starts or when the network restarts on Wednesday. We could also plug a monitoring solution such as the Prometheus + Grafana combo; a Grafana dashboard template for DAL nodes is available in Grafazos. The interactions between our baker and the Weeklynet chain can be observed on the Explorus block explorer which is aware of the DAL and can in particular display which DAL slots are being used at each level.
diff --git a/docs/tutorials/join-dal-baker/get-octez.md b/docs/tutorials/join-dal-baker/get-octez.md
new file mode 100644
index 000000000..a0f2d991a
--- /dev/null
+++ b/docs/tutorials/join-dal-baker/get-octez.md
@@ -0,0 +1,13 @@
+# Step 1: Get a Weeklynet-compatible Octez version
+
+The Weeklynet test network is restarted once every Wednesday at 0h UTC, and for most of its lifetime (from level 512) it runs a development version of the Tezos protocol, called Alpha, which is not part of any released version of Octez. For this reason, baking on Weeklynet requires to run Octez either with Docker using a specific Docker image, or by building it from source using a specific git commit.
+
+To get this specific Docker image, or the hash of this specific commit, see https://teztnets.com/weeklynet-about. This page also contains the proper `octez-node config init` incantation to configure the Octez node with the current network parameters of Weeklynet, the URL of a public RPC endpoint, and a link to a faucet distributing free testnet tez.
+
+For example, the commands to start a Docker image and configure the Octez node for the Weeklynet launched on January 17 2024, the instructions were:
+
+```
+docker run -it --entrypoint=/bin/sh tezos/tezos:master_7f3bfc90_20240116181914
+
+octez-node config init --network https://teztnets.com/weeklynet-2024-01-17
+```
diff --git a/docs/tutorials/join-dal-baker/prepare-account.md b/docs/tutorials/join-dal-baker/prepare-account.md
new file mode 100644
index 000000000..064fbd00e
--- /dev/null
+++ b/docs/tutorials/join-dal-baker/prepare-account.md
@@ -0,0 +1,57 @@
+# Step 3: Set up a baker account on Weeklynet
+
+Our baker needs an implicit account consisting of a pair of keys and an address. The simplest way to get them is to ask the Octez client to randomly generate them and associate them to the `my_baker` alias:
+
+```
+octez-client gen keys my_baker
+```
+
+The address of the generated account can be obtained with the following command:
+
+```
+octez-client show address my_baker
+```
+
+Let's record this address in a shell variable, this will be useful for the some commands which cannot get addresses by their octez-client aliases.
+
+```
+MY_BAKER="$(octez-client show address my_baker | head -n 1 | cut -d ' ' -f 2)"
+```
+
+At this point, the balance of the `my_baker` account is still empty as can be seen with the following command:
+
+```
+octez-client --endpoint "$ENDPOINT" get balance for my_baker
+```
+
+In order to get some consensus and DAL rights, we need to put some tez on the account. Fortunately, getting free testnet tez is easy thanks to the testnet faucet. To use it, we need to enter the generated address in the Weeklynet faucet linked from https://teztnets.com/weeklynet-about. We need at least 6k tez for running a baker but the more tez we have the more rights we will get and the shorter we will have to wait to produce blocks and attestations; that being said, baking with too much stake would prevent us from leaving the network without disturbing or even halting it so to avoid breaking the network for all other testers let's not be too greedy. 50k tez should be enough to get enough rights to easily check if our baker behaves as expected while not much disturbing the network when our baker will stop operating.
+
+Once the tez are obtained from the faucet, we can check with the same `get balance` command that they have been received:
+
+```
+octez-client --endpoint "$ENDPOINT" get balance for my_baker
+```
+
+At this point, the `my_baker` account owns enough stake to bake but has still no consensus nor DAL rights because we haven't declared to the Tezos protocol our intention to become a baker. This can be achieved with the following command:
+
+```
+octez-client --endpoint "$ENDPOINT" register key my_baker as delegate
+```
+
+Seven cycles later (about 1h40 on Weeklynet), our baker will start receiving rights. To see for instance its consensus attestation rights in the current cycle, we can use the following RPC:
+
+```
+octez-client --endpoint "$ENDPOINT" rpc get /chains/main/blocks/head/helpers/attestation_rights\?delegate="$MY_BAKER"
+```
+
+To see the DAL attestation rights of all bakers, we can use the following RPC:
+
+```
+octez-client --endpoint "$ENDPOINT" rpc get /chains/main/blocks/head/context/dal/shards
+```
+
+This command returns an array of DAL attestation rights. The 2048 shards which are expected to be attested at this level are shared between active bakers proportionally to their stake. Each baker is assigned a slice of shard indices represented in the output of this command by a pair consisting of the first index and the length of the slice. So to check if some rights were assigned to us we can filter the array to our baker by running this command:
+
+```
+octez-client --endpoint "$ENDPOINT" rpc get /chains/main/blocks/head/context/dal/shards | grep "$MY_BAKER"
+```
diff --git a/docs/tutorials/join-dal-baker/run-baker.md b/docs/tutorials/join-dal-baker/run-baker.md
new file mode 100644
index 000000000..141334146
--- /dev/null
+++ b/docs/tutorials/join-dal-baker/run-baker.md
@@ -0,0 +1,26 @@
+# Step 5: Run an Octez baking daemon on Weeklynet
+
+The baking daemon is launched almost as usual, the only difference is that we use the `--dal-node http://127.0.0.1` option to tell it to connect to the DAL node that we just launched in the previous step.
+
+```
+octez-baker-alpha run with local node "$HOME/.tezos-node" my_baker --liquidity-baking-toggle-vote on --adaptive-issuance-vote on --dal-node http://127.0.0.1 >> "$HOME/octez-baker.log" 2>&1
+```
+
+We can check that the DAL is now subscribed to the relevant topics by retrying the following RPC, which should now return all the topics of the form `{"slot_index":<index>,"pkh":"<ADDRESS OF OUR BAKER>"}` where `index` varies between `0` included and the number of slot indexes (`32` on Weeklynet) exluded:
+
+```
+curl http://localhost:10732/p2p/gossipsub/topics
+```
+
+We can also look at the baker logs to see if it manages to inject the expected operations. At each level, the baker is expected to:
+- receive a block proposal (log message: "received new proposal ... at level ..., round ...")
+- inject a preattestation for it (log message: "injected preattestation ... for my_baker (&lt;address&gt;) for level ..., round ...")
+- receive a block (log message: "received new head ... at level ..., round ...")
+- inject an attestation for it (log message: "injected attestation ... for my_baker (&lt;address&gt;) for level ..., round ...")
+- inject a DAL attestation indicating which of the shards assigned to the baker have been seen on the DAL network (log message: "injected DAL attestation ... for level ..., round ..., with bitset ... for my_baker (&lt;address&gt;) to attest slots published at level ..."); if no shard was seen (either because they did not reach the DAL node for some reason or simply because nothing was published on the DAL at the targetted level), the operation is skipped (log message: "Skipping the injection of the DAL attestation for attestation level ..., round ..., as currently no slot published at level ... is attestable.")
+
+Optionally, we can also launch an accuser which will monitor the behaviour of the other Weeklynet bakers and denounce them to the Tezos protocol if they are caught double-signing any block or consensus operation.
+
+```
+octez-accuser-alpha run >> "$HOME/octez-accuser.log" 2>&1
+```
diff --git a/docs/tutorials/join-dal-baker/run-dal-node.md b/docs/tutorials/join-dal-baker/run-dal-node.md
new file mode 100644
index 000000000..cfbd5fbca
--- /dev/null
+++ b/docs/tutorials/join-dal-baker/run-dal-node.md
@@ -0,0 +1,21 @@
+# Step 4: Run an Octez DAL node on Weeklynet
+
+```
+octez-dal-node run >> "$HOME/octez-dal-node.log" 2>&1
+```
+
+This, too, may take some time to launch the first time because it needs to generate a new identity file, this time for the DAL network.
+
+When running normally, the logs of the DAL node should contain one line per block applied by the layer 1 node looking like:
+
+```
+<timestamp>: layer 1 node's block at level <level>, round <round> is final
+```
+
+The DAL node we have launched connects to the DAL network but it is not yet subscribed to any Gossipsub topic. We can observe this by requesting the topics it registered to, using the following RPC:
+
+```
+curl http://localhost:10732/p2p/gossipsub/topics
+```
+
+In particular, it won't collect the shards assigned to our baker until it is subscribed to the corresponding topics. Don't worry, the baker daemon will automatically ask the DAL to subscribe to the relevant topics.
diff --git a/docs/tutorials/join-dal-baker/run-node.md b/docs/tutorials/join-dal-baker/run-node.md
new file mode 100644
index 000000000..8232802df
--- /dev/null
+++ b/docs/tutorials/join-dal-baker/run-node.md
@@ -0,0 +1,20 @@
+# Step 2: Run an Octez node on Weeklynet
+
+Once the Octez node has been configured to join Weeklynet, we can launch it and make its RPC available:
+
+```
+octez-node run --rpc-addr 127.0.0.1:8732 --log-output="$HOME/octez-node.log"
+```
+
+At first launch, the node will generate a fresh identity file used to identify itself on the Weeklynet L1 network, it then bootstraps the chain which means that it downloads and applies all the blocks. This takes a variable amount of time depending on when during the week these instructions are followed but at worse, on a tuesday evening, it takes a few hours. Fortunately, we can continue to set up our Weeklynet baking infrastructure while the node is bootstrapping, all we have to do for this is to use another, already bootstrapped, node as RPC endpoint for `octez-client` when we want to interact with the chain.
+
+A public RPC endpoint URL for Weeklynet is linked from the https://teztnets.com/weeklynet-about page, let's record it in a shell variable:
+```
+ENDPOINT="<URL of the RPC endpoint linked from https://teztnets.com/weeklynet-about>"
+```
+
+For example, for the Weeklynet launched on January 17 2024, the endpoint was:
+
+```
+ENDPOINT=https://rpc.weeklynet-2024-01-17.teztnets.com
+```
diff --git a/docusaurus.config.js b/docusaurus.config.js
index 26b5ba1fc..f2ba4c536 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -121,7 +121,7 @@ const config = {
       },
       prism: {
         theme: require('prism-react-renderer/themes/github'),
-        additionalLanguages: ['csharp'],
+        additionalLanguages: ['csharp', 'toml'],
       },
       // https://github.com/flexanalytics/plugin-image-zoom
       // Enable click to zoom in to large images
diff --git a/sidebars.js b/sidebars.js
index dae502ddc..8ace4d6d1 100644
--- a/sidebars.js
+++ b/sidebars.js
@@ -341,6 +341,36 @@ const sidebars = {
             'tutorials/smart-rollup/run',
           ],
         },
+        {
+          type: 'category',
+          label: 'Implement a file archive with the DAL',
+          link: {
+            type: 'doc',
+            id: 'tutorials/build-files-archive-with-dal',
+          },
+          items: [
+            'tutorials/build-files-archive-with-dal/get-dal-params',
+            'tutorials/build-files-archive-with-dal/get-slot-info',
+            'tutorials/build-files-archive-with-dal/publishing-on-the-dal',
+            'tutorials/build-files-archive-with-dal/using-full-slot',
+          ],
+        },
+        {
+          type: 'category',
+          label: 'Join the DAL as a Weeklynet baker',
+          link: {
+            type: 'doc',
+            id: 'tutorials/join-dal-baker',
+          },
+          items: [
+            'tutorials/join-dal-baker/get-octez',
+            'tutorials/join-dal-baker/run-node',
+            'tutorials/join-dal-baker/prepare-account',
+            'tutorials/join-dal-baker/run-dal-node',
+            'tutorials/join-dal-baker/run-baker',
+            'tutorials/join-dal-baker/conclusion',
+          ],
+        },
         {
           type: 'category',
           label: 'Build an NFT marketplace',
diff --git a/static/img/tutorials/dal-explorus-slots.png b/static/img/tutorials/dal-explorus-slots.png
new file mode 100644
index 000000000..01978f187
Binary files /dev/null and b/static/img/tutorials/dal-explorus-slots.png differ