change ids

website/docs/developers/device/encryption.md

@@ -1,5 +1,5 @@
 ---
-id: security-device-developer
+id: encryption
 title: Meshtastic encryption
 sidebar_label: Encryption
 ---

website/docs/developers/device/port-numbers.md

@@ -1,5 +1,5 @@
 ---
-id: portnum-device-developer
+id: portnum
 title: Meshtastic port numbers
 sidebar_label: Port numbers
 ---

website/docs/legal/overview.md

@@ -9,7 +9,7 @@ slug: /legal
 This project is still pretty young but moving at a pretty good pace. Not all features are fully implemented in the current alpha builds.
 
 * We don't make these devices and they haven't been tested by UL or the FCC. If you use them you are experimenting and we can't promise they won't burn your house down ;-)
-* The encryption implementation is good but see this list of [caveats](/docs/developers/device/security-device-developer#summary-of-strengthsweaknesses-of-our-current-implementation) to determine risks you might face.
+* The encryption implementation is good but see this list of [caveats](/docs/developers/device/encryption#summary-of-strengthsweaknesses-of-our-current-implementation) to determine risks you might face.
 
 ## Legal FAQ
 

website/docs/software/device/critical-faults.md

@@ -1,5 +1,5 @@
 ---
-id: critical-error-device
+id: critical-error-codes
 title: Critical error codes
 sidebar_label: Critical error codes
 ---

website/docs/software/other/mesh-alg.md

@@ -26,7 +26,7 @@ After the preamble the 16 byte packet header is transmitted. This header is desc
 - id (4 bytes): the unique (wrt the sending node only) packet ID number for this packet. We use a large (32 bit) packet ID to ensure there is enough unique state to protect any encrypted payload from attack.
 - flags (4 bytes): Only a few bits are are currently used - 3 bits for for the "HopLimit" (see below) and 1 bit for "WantAck"
 
-After the packet header the actual packet is placed onto the the wire. These bytes are merely the encrypted packed protobuf encoding of the SubPacket protobuf. A full description of our encryption is available in [crypto](/docs/developers/device/security-device-developer). It is worth noting that only this SubPacket is encrypted, headers are not. Which leaves open the option of eventually allowing nodes to route packets without knowing the keys used to encrypt.
+After the packet header the actual packet is placed onto the the wire. These bytes are merely the encrypted packed protobuf encoding of the SubPacket protobuf. A full description of our encryption is available in [crypto](/docs/developers/device/encryption). It is worth noting that only this SubPacket is encrypted, headers are not. Which leaves open the option of eventually allowing nodes to route packets without knowing the keys used to encrypt.
 
 NodeIds are constructed from the bottom four bytes of the macaddr of the bluetooth address. Because the OUI is assigned by the IEEE and we currently only support a few CPU manufacturers, the upper byte is defacto guaranteed unique for each vendor. The bottom 3 bytes are guaranteed unique by that vendor.
 

website/sidebars.js

@@ -19,7 +19,7 @@ module.exports = {
       "software/overview",
       {
         "Meshtastic device": [
-          "software/device/critical-error-device",
+          "software/device/critical-error-codes",
         ],
       },
       {
@@ -107,8 +107,8 @@ module.exports = {
       {
         Device: [
           "developers/device/radio-settings",
-          "developers/device/security-device-developer",
+          "developers/device/encryption",
-          "developers/device/portnum-device-developer",
+          "developers/device/portnum",
           "developers/device/supported-hardware",
           "developers/device/http-api",
           "developers/device/documents",