New EDITOR section (#415)

* new EDITOR section * fix links * multiple edits * more additions * fix link * adjust image sizes and more * smart items as section * reorder pages * expand more * publish scene - first iteration * fixes * retouch intro * polish editor essentials * test * test 2 * bigger titles * bigger titles * interlinks * overall diagram * fix links * fix link * images * test * title sizes * many renames and other changes * feat: change h6 by h5 * feat: update theme with heading * h4 > h3 * Creators Hub > Creator Hub * many changes * many changes * 3d content essentials parts * many fixes * quickstart first draft * enhancements * refine * finish tutorial * fixes * rearrange creator landing * Creator Hub, not Creators Hub * adjustments * bigger image * retouches * retouches * camera-first-draft * camera docs * deprecated section * fix links * default transition to all camera snippets * remove comment * minor fixes to camera * trigger area and streaming * creator hub rename * mention templates * fixes to camera * debug in preview * single player scenes (#435) * input modifiers * retouches * polish 101 tutorial * add image of avocado * fix CLI command * adjust image sizes * warning about user data * emotes texture size * reload when debugging * version control * video player basic material * fix link * warnings * global sounds * more direct download link * player docs edits * whitepaper * URL links to DCL on new client * fix whitepaper links * test YT video * update YT videos * isStateSynced * retuouch isSynced snippet * isSynced retouches --------- Co-authored-by: Braian Mellor <[email protected]>
decentraland · Oct 22, 2024 · efc802b · efc802b
1 parent c9af1b1
commit efc802b
Show file tree

Hide file tree

Showing 227 changed files with 5,719 additions and 3,996 deletions.
diff --git a/README.md b/README.md
@@ -18,7 +18,7 @@
 More info: https://gohugo.io/content-management/cross-references/
 
 ```markdown
-To publish [publish]({{< ref "/content/creator/scenes/publishing/publishing.md" >}}) your scene bla bla bla
+To publish [publish]({{< ref "/content/creator/deprecated/scenes/publishing/publishing.md" >}}) your scene bla bla bla
 ```
 
 ---

diff --git a/content/contributor/auth/authchain.md b/content/contributor/auth/authchain.md
@@ -4,7 +4,6 @@ url: /contributor/auth/authchain
 weight: 2
 ---
 
-
 Many actions in the Decentraland protocol either require or benefit from authorization with a signature from the user's Ethereum account. For example:
 
 1. Upload a new version of any [Entity]({{< ref "/contributor/content/entities" >}}) they own (such as their profile).
@@ -13,7 +12,6 @@ Many actions in the Decentraland protocol either require or benefit from authori
 
 To perform these actions, users and delegates must sign payloads describing their intent and produce an _authentication chain_.
 
-
 ## Introduction
 
 Authentication chains encapsulate a series of verification steps, with each step depending on the succcessful verification of the previous one. All steps must be deemed valid by the verifier for any restricted action to take place.
@@ -47,11 +45,11 @@ This single-delegate chain is the most common form of authorization used in Dece
 
 Each step in the authentication chain contains three pieces of information: a `type`, a `payload` and a corresponding `signature`.
 
-| Field | Value |
-| ----- | --- |
-| `type` | The name of a type ([see below](#types)).
-| `payload` | A type-dependent string.
-| `signature` | The hex-encoded Ethereum signature of `payload`, beginning with `0x`.
+| Field       | Value                                                                 |
+| ----------- | --------------------------------------------------------------------- |
+| `type`      | The name of a type ([see below](#types)).                             |
+| `payload`   | A type-dependent string.                                              |
+| `signature` | The hex-encoded Ethereum signature of `payload`, beginning with `0x`. |
 
 {{< info >}}
 Since the most common serialization of an authentication chain is a JSON array, the examples below are presented in that form. See [Transmitting a Chain](#transmitting) for more details.
@@ -80,7 +78,7 @@ The second step must carry a `signature` from this account for its `payload`.
 
 ### Intermediate Steps: Delegation
 
-When delegates are acting on the user's behalf, an item is added to the middle of the chain for each of them. The conditions for these steps are: 
+When delegates are acting on the user's behalf, an item is added to the middle of the chain for each of them. The conditions for these steps are:
 
 1. The type is [`ECDSA_EPHEMERAL`](#ECDSA_EPHEMERAL)
 2. The `payload` is a specially crafted text (see below).
@@ -164,7 +162,6 @@ There is no universal strategy to decide what the valid time window should be. T
 Ephemeral keys should never hold funds or possess the ability to transfer digital assets. It's much safer for end-users if the leak of an ephemeral key cannot result in financial losses.
 {{< /info >}}
 
-
 ## Formalization
 
 What follows is a more formal and precise definition of the processes involved. Follow these instructions to successfully handle authentication chains.
@@ -174,80 +171,85 @@ What follows is a more formal and precise definition of the processes involved.
 Clients crafting an authentication chain for the user follow these steps:
 
 1. Add the identification step:
-    1. Set the `type` to `SIGNER`.
-    2. Set the `payload` to the user's Ethereum address.
-    3. Set the `signature` to an empty string.
+
+   1. Set the `type` to `SIGNER`.
+   2. Set the `payload` to the user's Ethereum address.
+   3. Set the `signature` to an empty string.
 
 2. Add delegations steps:
-      1. Generate or use an existing delegate private key (may require interaction).
-      2. Calculate the delegate Etherum address derived from the corresponding public key.
-      3. Set the `type` to `ECDSA_EPHEMERAL`.
-      4. Set the `expiration` to a date in the future.
-      5. Choose a `purpose` for this key.
-      5. Set the `payload` to this exact form:
-          ```md
-          <purpose>
-          Ephemeral address: <delegate-address>
-          Expiration: <date>
-          ```
-      6. Set the `signature` field to the `payload` signature from the previous key (user or delegate).
-      7. Repeat for all successive delegates.
-
-  3. Add the action authorization step:
-      1. Set the `type` to a valid value ([see below](#types))
-      2. Set the `payload` to the type-specific value (such as the entity ID).
-      3. Set the `signature` field to the `payload` signature from the previous key (user or delegate).
-
-  4. Send the authentication chain to the verifier.
+
+   1. Generate or use an existing delegate private key (may require interaction).
+   2. Calculate the delegate Etherum address derived from the corresponding public key.
+   3. Set the `type` to `ECDSA_EPHEMERAL`.
+   4. Set the `expiration` to a date in the future.
+   5. Choose a `purpose` for this key.
+   6. Set the `payload` to this exact form:
+      ```md
+      <purpose>
+      Ephemeral address: <delegate-address>
+      Expiration: <date>
+      ```
+   7. Set the `signature` field to the `payload` signature from the previous key (user or delegate).
+   8. Repeat for all successive delegates.
+
+3. Add the action authorization step:
+
+   1. Set the `type` to a valid value ([see below](#types))
+   2. Set the `payload` to the type-specific value (such as the entity ID).
+   3. Set the `signature` field to the `payload` signature from the previous key (user or delegate).
+
+4. Send the authentication chain to the verifier.
 
 ### Verification
 
 Content servers and 3rd-party services implementing verification follow these steps:
 
 1. Verify identification:
-    1. Verify the `type` is `SIGNER`.
-    2. Verify the `payload` is the Ethereum address of the user.
-    3. Verify the `signature` is an empty string.
+
+   1. Verify the `type` is `SIGNER`.
+   2. Verify the `payload` is the Ethereum address of the user.
+   3. Verify the `signature` is an empty string.
 
 2. Verify delegates:
-    1. Verify the `type` is `ECDSA_EPHEMERAL`.
-    2. Verify the `payload` is in this form and extract the fields:
-        ```md
-        <purpose>
-        Ephemeral address: <delegate-address>
-        Expiration: <date>
-        ```
-    3. Verify the `date` is still in the future.
-    4. Verify the `purpose` is supported by your service.
-    4. Verify the `signature` is valid for the given `payload` and the previous public key.
-    6. Repeat for all successive delegates.
+
+   1. Verify the `type` is `ECDSA_EPHEMERAL`.
+   2. Verify the `payload` is in this form and extract the fields:
+      ```md
+      <purpose>
+      Ephemeral address: <delegate-address>
+      Expiration: <date>
+      ```
+   3. Verify the `date` is still in the future.
+   4. Verify the `purpose` is supported by your service.
+   5. Verify the `signature` is valid for the given `payload` and the previous public key.
+   6. Repeat for all successive delegates.
 
 3. Verify action authorization:
-    1. Verify the `type` is a valid value ([see below](#types)).
-    2. Verify the `payload` is valid for this `type`.
-    3. Verify the `signature` is valid for the given `payload` and the previous public key.
 
-4. Accept the authentication chain.
+   1. Verify the `type` is a valid value ([see below](#types)).
+   2. Verify the `payload` is valid for this `type`.
+   3. Verify the `signature` is valid for the given `payload` and the previous public key.
 
+4. Accept the authentication chain.
 
 ### Standard Action Types and Purposes {#types}
 
 The `type` and `payload` values for identification and delegation are standard and must be verified as laid out above, but clients and services can agree on any action `type`, and its `payload` structure, as well as set a `purpose` for their delegate keys that they consider valid.
 
 The protocol defines three standard types, and one standard purpose:
 
-###### Type `SIGNER` {#SIGNER}
+##### Type `SIGNER` {#SIGNER}
 
 **Must** be the initial `type` in the chain, where `payload` is the user's Ethereum address and `signature` is an empty string.
 
-###### Type `ECDSA_EPHEMERAL` {#ECDSA_EPHEMERAL}
+##### Type `ECDSA_EPHEMERAL` {#ECDSA_EPHEMERAL}
 
 **Must** be the `type` for intermediate steps in the chain, where `payload` is in the form described above.
 
-###### Type `ECDSA_SIGNED_ENTITY` {#ECDSA_SIGNED_ENTITY}
+##### Type `ECDSA_SIGNED_ENTITY` {#ECDSA_SIGNED_ENTITY}
 
 The final `type` in the chain for authorizing entity deployments, where `payload` is the ID of an entity owned by the user.
 
-###### Purpose `Decentraland Login` {#DecentralandLogin}
+##### Purpose `Decentraland Login` {#DecentralandLogin}
 
-The usual `purpose` for World Explorers, signed both when logging into the world and when renewing their delegate key.
+The usual `purpose` for World Explorers, signed both when logging into the world and when renewing their delegate key.