[Feature Request]: Web Client features we might like. #967
Description
Prerequisites
- I have searched existing issues to ensure this feature hasn't already been requested
- I have checked the documentation to verify this feature doesn't already exist
Problem Statement
-Nodes cannot connect simultaneously.
-Statistics and debug information page be present on the web client.
-DONE On the map include a heat map.
-Hard to notice private direct messages.
-Bots we need bots. :)
-Node encryption lock errors.
-Security Admin Encryption.
-Admin Commands.
-Include factory node name Hex ID.
-Parse LoRa/Mqtt traffic as a different colour.
-Addressing channel names.
-Mobile browser support.
Proposed Solution
-"Nodes cannot connect simultaneously" Within the meshtastic web client for docker we allow the web client to act as a intermediary for TCP connection between the metastatic web client and the meshtastic device and the mobile web application assuming bluetooth is not primarily used directly from device to meshtastic node. Bluetooth could be used in this fashion as well if their is access to bluetooth from the docker web client serving system. Similar simultaneous connectivity discussed in part with #724 however I don't think it's quite similar enough.
-"Statistics and debug information page be present on the web client" I would like statistical data ie. uptime, reboot count, channel usage observation, channel / radio preset information, and a raw live stream of debug information. Anything that would assist in troubleshooting radio anomalies, or assist in improving radio conditions in a localized area. Some configured information is preset at http://ipaddress/json/report lets unify it all into one location.
-"On the map include a heat map" Base it on SNR of nodes within the zone. Alternatively you can also base it on observed channel utilization as the channel becomes more utilized display a % and increase the gradient into red. For OCU you could also add a pulse/wave that direct out or in from a centre radius this would indicate if your the offending utilization or if it’s coming from another node.
-"Hard to notice private direct messages" When a direct message as been received or sent place the direct message for that node under the channel sidebar to the left. Add a x to allow you to quickly dismiss the node message back into the node list. Maybe limit to the most recent 5 to avoid over crowding the left channel list.
-"Bots we need bots :)" I've noticed a growing trend in related third party meshtastic web clients that greeting, and responsive bots are being deployed to allow automated responses to simple inquiry's like can anyone hear me?, ping/pong, test ect. I find this useful if directed to private messages so bot activity doesn't flood public traffic and allows node owners to step away and let the bot reply autonomously.
-"Node encryption lock errors" eg. red lock error. when hovering over the red lock display the exact error and description of how to correct this error.
-"Security Admin Encryption" This confused me initially because it's the reverse of how you would use private / public key's in most servers. For meshtastic the device keeps the private key, and you hand out the public key I don't believe this is well explained and could use some clarification within the security page.
-"Admin Commands" Allow admin commands to be sent from the web client.
-"Include factory node name Hex ID" Eg. Plugged in, Voltage: 4.38 V, Firmware: 2.7.15.567b8ea, Factory Node Name Hex ID: #########. The reason I would like this included is because in situations like with mqtt maps the full display name or short name might be replaced by the factory node name Hex ID and in certain mqtt brokers statistical data. Being able to quickly reference the factory node name Hex ID is useful.
-"Parse LoRa/Mqtt traffic as a different colour" For those that use mqtt to receive and relay traffic it's difficult to know which traffic is local and which traffic is being relayed from mqtt. By differentiating the traffic by colour we could tell if the message received is local, mqtt, or received on both.
-"Addressing channel names" In some instances you may want to have the primary channel as a encrypted private channel so you can receive/send automatic positional broadcasts. But you might also want a secondary channel to receive public messages on. For example the radio preset LongFast on primary is a blank channel name with a 8 bit AQ== as it's password. The firmware however sees this channel name as "LongFast" if you leave the name blank you get a channel name like # page.channelLabel 
This isn't the most elegant label, however if you set the channel name as LongFast you get LongFast as the channel label. Both are accurate methods of setting the channel name for public traffic on LongFast. But keeping the names the same would be preferred to be LongFast.
-"Mobile Browser support" Backlogged for #666 At least from my experience I have found the web client when used with a mobile brower over tcp, does not render correctly to scale and infinitely loads with a spinning wheel. I have troubleshooted the issue and it actually used to load correctly back in web client #284CCD4, but since this version has not loaded.
Current Alternatives
No response
Importance
Nice to have
Additional Context
Anyways this is a quick rundown on features that I think would be interesting to have on the Meshtastic Web Client. If I stepped on anyone feature requests I apologize maybe drop your related feature request link on mine or on yours so we have some crossover if that sounds appropriate.
I want to just say the web client stable and nightly has been a lifeline since I don't use the meshtastic mobile application currently due to needing to upgrade my phone, and I appreciate the developers and contributors time. I've seen what some third party apps are doing and the possibility's this web client could implement would be awesome. I appreciate those developers as well. Whats the saying "Imitation is the sincerest form of flattery that mediocrity can pay to greatness"