Optional
data: PartialMessage<ChannelSettings>Deprecated in favor of LoraConfig.channel_num
from field: uint32 channel_num = 1 [deprecated = true];
If true, messages seen on the internet will be forwarded to the local mesh.
from field: bool downlink_enabled = 6;
Used to construct a globally unique channel ID. The full globally unique ID will be: "name.id" where ID is shown as base36. Assuming that the number of meshtastic users is below 20K (true for a long time) the chance of this 64 bit random number colliding with anyone else is super low. And the penalty for collision is low as well, it just means that anyone trying to decrypt channel messages might need to try multiple candidate channels. Any time a non wire compatible change is made to a channel, this field should be regenerated. There are a small number of 'special' globally known (and fairly) insecure standard channels. Those channels do not have a numeric id included in the settings, but instead it is pulled from a table of well known IDs. (see Well Known Channels FIXME)
from field: fixed32 id = 4;
Optional
modulePer-channel module settings.
from field: meshtastic.ModuleSettings module_settings = 7;
A SHORT name that will be packed into the URL. Less than 12 bytes. Something for end users to call the channel If this is the empty string it is assumed that this channel is the special (minimally secure) "Default"channel. In user interfaces it should be rendered as a local language translation of "X". For channel_num hashing empty string will be treated as "X". Where "X" is selected based on the English words listed above for ModemPreset
from field: string name = 3;
A simple pre-shared key for now for crypto.
Must be either 0 bytes (no crypto), 16 bytes (AES128), or 32 bytes (AES256).
A special shorthand is used for 1 byte long psks.
These psks should be treated as only minimally secure,
because they are listed in this source code.
Those bytes are mapped using the following scheme:
0
= No crypto
1
= The special "default" channel key: {0xd4, 0xf1, 0xbb, 0x3a, 0x20, 0x29, 0x07, 0x59, 0xf0, 0xbc, 0xff, 0xab, 0xcf, 0x4e, 0x69, 0x01}
2
through 10 = The default channel key, except with 1 through 9 added to the last byte.
Shown to user as simple1 through 10
from field: bytes psk = 2;
If true, messages on the mesh will be sent to the public internet by any gateway ndoe
from field: bool uplink_enabled = 5;
Static
Readonly
fieldsStatic
Readonly
runtimeStatic
Readonly
typeCreate a deep copy.
Compare with a message of the same type. Note that this function disregards extensions and unknown fields.
Parse from binary data, merging fields.
Repeated fields are appended. Map entries are added, overwriting existing keys.
If a message field is already present, it will be merged with the new data.
Optional
options: Partial<BinaryReadOptions>Retrieve the MessageType of this message - a singleton that represents the protobuf message declaration and provides metadata for reflection- based operations.
Protected
toJSONOverride for serialization behavior. This will be invoked when calling JSON.stringify on this message (i.e. JSON.stringify(msg)).
Note that this will not serialize google.protobuf.Any with a packed message because the protobuf JSON format specifies that it needs to be unpacked, and this is only possible with a type registry to look up the message type. As a result, attempting to serialize a message with this type will throw an Error.
This method is protected because you should not need to invoke it directly -- instead use JSON.stringify or toJsonString for stringified JSON. Alternatively, if actual JSON is desired, you should use toJson.
Static
equalsStatic
fromOptional
options: Partial<BinaryReadOptions>Static
fromOptional
options: Partial<JsonReadOptions>Static
fromOptional
options: Partial<JsonReadOptions>Generated using TypeDoc
This information can be encoded as a QRcode/url so that other users can configure their radio to join the same channel. A note about how channel names are shown to users: channelname-X poundsymbol is a prefix used to indicate this is a channel name (idea from @professr). Where X is a letter from A-Z (base 26) representing a hash of the PSK for this channel - so that if the user changes anything about the channel (which does force a new PSK) this letter will also change. Thus preventing user confusion if two friends try to type in a channel name of "BobsChan" and then can't talk because their PSKs will be different. The PSK is hashed into this letter by "0x41 + [xor all bytes of the psk ] modulo 26" This also allows the option of someday if people have the PSK off (zero), the users COULD type in a channel name and be able to talk. FIXME: Add description of multi-channel support and how primary vs secondary channels are used. FIXME: explain how apps use channels for security. explain how remote settings and remote gpio are managed as an example
Generated
from message meshtastic.ChannelSettings