the ID being used is cryptographically random. its generated automatically client-side and should have good conflict resilience so someone cant guess the ID to connect to you.
that ID is used with the peerjs-server (open source, selfhostable), which is being used as the connection broker to establish a webrtc connection. Webrtc is a browser-to-browser connection and avoids routing through a central server. encryption keys are established in the initial connection on client-side. this can be used to achieve p2p authentication (without centralisation) for future sessions.
ongoing investigation: its also possible to bypass the peerjs-server entirely by acting as your own peer-broker, but i havent figured out a nice user experience for me to roll this out anytime soon. id like to investigate about exchanging the information needed over QR codes, BLE or NFC. the key tradoff is that users have to be in the same physical location. https://github.com/positive-intentions/chat/issues/6
javascript over the internet can be be intercepted by a network admin or ISP. if acting maliciously, then it could swap the static js files for their own. particularly concern for webapps because every time you load the webpage, it would load the latest statics, which could have been altered on the network level to provide comprimised functionality. id like to have the service worker cache the statics to avoid that issue. it might be also worth repeating that you can just run the index.html in a browser to avoid fetching new statics. the app is ultimately provided as a webapp to help users get started... because it doesnt rely on knowing seemingly basic things like "how to run the index.html file in a browser" (which, im sure i know many people who dont... and i suspect thats the majority of the users)
thats the whole point. we step away from "iOS and Android" and enable users to run this on their platform-of-choice. generally, all "modern" operating systems support browsers out-the-box. users should be responsible with how they run this app: e.g. if you trust firefox more than chrome.
im using the metered.ca turn servers because they have a free plan (more than enough when i limit it to only brokering p2p connections). you have the option to use your own api key to do things like enable a "relay-mode", which will proxy all messages. using the api key is simple UI abstraction for users to configure a TURN/STUN server. im open to make this as configurable as nessesary if users want to add multiple of their own servers.
"reliable" is a relative term. its entirely possible a centralized backend goes down. its a known fact that in a p2p architecture, peers have to be online to recieve messages... while you dont have things like the ability to send messages offline, there is no backend server in the p2p architecture to go down.
meshtastic is a great solution. i bought a couple units to try it out to integrated their app into my webapp: https://chat.positive-intentions.com/#/meshtastic ... its basically a wrapper within my app. i wouldnt plan for go "all in" on meshtastic at all, but i see that it could be useful for smaller payloads (loads more investigation needs to be done to have anything usable). my app is speciafically based on webrtc, which has unparalelled transfer speeds; which is especially useful when sending large files. meshtastic could struggle to exchange a gif. meshtastics has a good reputation in cyber-sec, but i suspect it isnt more popular because people want modern messaging app multimedia capabilities. my app is presented as a webapp specifically for the average joe to get started.
ultimately, its always worth repeating that this is a work in progress and not redy to replace any of the existing app or services.