Option for chat rooms and unencrypted messages

There has been some discussion about adding chatrooms to Meshtastic. That could be done within the app only, or on mesh protocol level.

If the rooms are created and maintained strictly within the app, the workflow could be something like this:

  • open the app and connect to the mesh
  • add a room with a long name and a short name
  • send the room information to all nodes within the mesh, as a broadcast, as a normal text message
  • the recipient app parses the information and adds the room #1 to be visible for all users
  • when a user send messages within the room, the message starts with the room number (#1), and is broadcasted to all members as a normal text
  • the recipient app parses the text and shows the message within the room #1

If rooms are handled strictly within the app, as described, every message would always be broadcasted (flooded) to all nodes, as we can not route one message to selected couple of recipients. This could jam the mesh. Optionally, the user could invite only certain users to the room, and the room information could be sent only to room members (as separate unicast messages). This would work for only a couple of users, as messages within the room populates separate unicast packets for every user on the room. This could also eventually jam the mesh.

If the rooms would be supported within the mesh routing protocol, the workflow could be something like this:

  • open the app and connect to the mesh
  • add a room with a long name and a short name
  • broadcast the room information to all nodes within the mesh as a defined room -type message (add or remove)
  • all nodes do add this room to their database (to avoid rooms with the same name later), and the nodes then add a room specific ID (virtual node ID) they listens messages for
  • the nodes joined the room send a ACK of the added room with its room ID, to notify the mesh (to update the routing tables of other mesh nodes)
  • the node then advertise the room for only the invited users app
  • the app shows the room for users invited to the room
  • when a user sends text within the room, the node adds the room ID as the packet recipient
  • the node unicast the packet to the mesh, for only the room members (as one routed packet)
  • the room member nodes listen to the room packets and forwards it to the app

This would minimize the need to do broadcast on the whole mesh, or send separate unicast packets for every room member. Unfortunately, linking room IDs and node IDs would need a) ACKs sent from nodes within the room (to notify the mesh nodes to update their node databases), b) advertising room membership in some another way, or c) not being sure the messages are routed correctly.

There are two unsolved interesting parts. First, how to unicast one packet to many recipients (add all recipients to the header separately, or add a message type indicating room #). Second, how to update the node databases of nodes registered to a certain room (using room specific node IDs when a node is sending, or advertising and adding a linkage of the room # to the node databases).

Optionally, there could be a possibility to crypt messages per room. This could be done with a separate PSK shared by room members. The app could crypt and decrypt messages with a separate key depending on the room.

To add, there should be a way to send unencrypted messages within the mesh, to be sure all mesh participants can receive emergency messages. The emergency messages should be highlighted the way they are not missed. I believe this was already mentioned somewhere.

Please comment and correct me freely.


hmm. Good idea. That is somewhat similar to how Channels are implemented currently. A Channel is really just three tings:

  • A name - which gets hashed to generate a numeric channel number (indirectly the frequency)
  • A private key (which is currently disabled per the faq/disclaimers - will be added by 1.0) which is used to encrypt all traffic for that channel.

The nodes will actually route/forward any valid packet on their current frequency. Eventually what you describe could be done by:

  • Possibly exposing the channel number to the user (so they would then have to be aware of this concept
  • Giving a user interface so a user can subscribe to multiple channels at once (currently there is only one channel used at a time)
  • Giving a UX in the app so they can have different chat sessions for each channel

Also - within a few weeks there should be an exposed API so that other apps (either on a phone or on a PC) can send/receive packets and just use meshtastic as a transport for whatever they want.

The simplicity of the app, including the other parts of this project as well, is greate. The ability to communicate with all channel users are nice, and all hikers can start using the app with minimal knowledge of the system.

There could be these logical ways to send text messages between users:

  • a chat for one to all mesh users (default cryptography)
  • one to one text messages (whoever on the mesh, default cryptography)
  • public rooms within the mesh (all users can join and use the room, default cryptography)
  • private rooms for one to many (selected users, private PSK)
  • unencrypted room for everyone to send emergency messages (totally unencrypted, whoever on the MHz band can open the plain modulation)

Private rooms could be using a different PSK, but the same mesh network settings.

Rooms can be problematic, as they might increase amount of packets. If there are a lot of users within the rooms, unicast messages might become as dense as broadcast messages on the mesh (as almost all messages has to be sent to several nodes).

What about renaming channel to network settings or similar, to empathize the differences between chat rooms, the physical networking settings, and mesh settings? Settings should still be easily set up (working defaults).

The API is a really great feature!


Those are really good points. I’m making them into an issue so we don’t forget to work on this after the 1.0 release. I really would like to do this someday, but my personal queue is full for the next few weeks on getting everything solid, 1.0 out and finishing the remaining missing features listed in the faq.

1 Like