Linux CLI NodeID Base64URL Weirdness

[SecareLupus]

Describe the bug
I harvested nodeid from an agent with the command
HEX_VALUE=$(sudo /usr/local/mesh_services/meshagent/meshagent -nodeid)
I converted this value to Base64 with the command
NODE_ID=$(echo "$HEX_VALUE" | xxd -r -p | base64)
This value includes '+' and '/' characters, so I would presumably convert them to '-' & '_' respectively to meet Base64URL standard, but the actual nodeID used in the web app and meshctrl.js seems to swap in the characters '@' & '$' (respectively) for the illegal characters instead.

Is this intended behavior? Is this documented anywhere? Very few references to the meshagent -nodeid even mention that it /isn't/ a ready to use value but a Hex value, and I'm not familiar with base64url encoding acting this way.

To Reproduce
Steps to reproduce the behavior:

1. Install agent on linux
2. sudo /usr/local/mesh_services/meshagent/meshagent -nodeid | xxd -r -p | base64
3. Compare output to nodeID value in WebApp URL

Expected behavior
$HEX_VALUE
=base64=>
SpN4i+bpu/bM
=base64URL=>
SpN4i-bpu_bM
=In URL=>
mesh.com/?gotonode=SpN4i-bpu_bM
Actual URL: mesh.com/?gotonode=SpN4i@bpu$bM

Server Software:

• OS: Debian Container
• Virtualization: TyphoonWind Docker Compose, hosted on Debian LXC Container on Proxmox VE
• Network: LAN/WAN, NGINX Proxy Manager, SSL Managed by NGINX PM via Let's Encrypt
• Version: 1.1.32
• Node: Unknown, TyphoonWind Docker Compose used with standard updates.

Client Device:
Not Applicable

Remote Devices:

• Device: Raspberry Pi 4B Embedded Device Fleet | Ubuntu Desktop Workstation
• OS: Debian Bullseye (Custom Build) | Ubuntu 24.10
• Network: Remote over WAN | Remote over WAN
• Current Core Version: Workstation uses Nov 21 2022, 2018810399

Your config.json file

{
  "$schema": "http://info.meshcentral.com/downloads/meshcentral-config-schema.json",
  "settings": {
    "cert": "mesh.COMPANYNAME.com",
    "_WANonly": true,
    "_LANonly": true,
    "sessionKey": "PASSWORD",
    "port": 443,
    "_aliasPort": 443,
    "redirPort": 80,
    "_redirAliasPort": 80,
    "RelayDNS": "relay.mesh.COMPANYNAME.com",
    "AgentPong": 300,
    "TLSOffload": false,
    "trustedProxy": "PROXY_IP,ROUTER_IP",
    "SelfUpdate": false,
    "allowLoginToken": true,
    "allowFraming": true,
    "mongodb": "mongodb://mongodb:27017/mesh",
    "mongodbcol": "mesh",
    "WebRTC": true,
    "desktopMultiplex": true,
    "cookieIpCheck": "none",
    "sessionSameSite": "lax",
    "plugins": { "enabled": true }
  },
  "domains": {
    "": {
      "title": "COMPANYNAME",
      "title2": "Internal Mesh",
      "_minify": true,
      "NewAccounts": "false",
      "_userNameIsEmail": true,
      "certUrl": "https://PROXY_IP:443",
      "passwordRequirements": {
        "force2factor": true,
	"autofido2fa": true
      }
    }
  },
  "_letsencrypt": {
    "__comment__": "Requires NodeJS 8.x or better, Go to https://letsdebug.net/ first before>",
    "_email": "[email protected]",
    "_names": "myserver.mydomain.com",
        "production": false
  }
}

[si458]

you have to simply replace values with the correct things to get the correct nodeid
this is my nodejs code which might help you #5202 (comment)
i always wondered why -nodeid never returned the actually nodeid but it required the hex value which still needs to be base64 encoded and then values replaced

[SecareLupus]

Yes, I meant to update this ticket, I changed my script to use the statement:
meshNodeID=$(sudo /usr/local/mesh_services/meshagent/meshagent -nodeid | xxd -r -p | base64 | tr '/+' '$@')
and that provided the correct node id for my purposes. I was mostly checking whether this was intended behavior, given the hex output and seemingly non-standard base64 formatting.

It seemed like there was probably a reason for using this encoding instead of standard base64URL, but it's not an encoding I've ever seen before, and I wasn't sure whether it was bespoke. Thank you for switching it to a question, btw, I didn't see a way to submit it as a question myself.