Option for channels?
cyclomies opened this issue · 4 comments
There could be an option to join a specific channel?
This could be done by (a quick list):
- reserving specific (broadcasted) node addresses for channels, and adding selected to be listened on the node
- adding a byte to the header (selected listened on the node)
- adding a specific entry to the payload (recognized by the application layer)
- done purely only on application level by selecting contacts to the channel (as suggested by @samuk)
The sender, within the channel, would send messages with its own node ID to be correctly identified in routing tables.
I'm not sure I quite get what you mean. It has occurred to me that on the client-side you could create 'rooms' where you just display content from specific nicknames or tags. Do you need to do anything to the protocol to achieve this? Isn't it all just the client-side?
I'm not sure I quite get what you mean. It has occurred to me that on the client-side you could create 'rooms' where you just display content from specific nicknames or tags. Do you need to do anything to the protocol to achieve this? Isn't it all just the client-side?
That (adding the information to the payload by the app, or do it only within the app) would work, but there are drawbacks for airtime:
If rooms/channels are maintained purely within the application, then you have to send every message to everyone participating the room as separate messages (as every message is node-specific: packet header has to be coded for all separate nodes for all participants).
If channels would be handled/supported on the protocol level, the users node could send one packet for one message on the channel/room, targeted to all channel members, to be routed to all participant nodes by only one packet (as all nodes on the channel would pick the message indicated for the channel).
Not a bad suggestion, basically multicast addresses,right? It's something I have considered, but a) haven't had time to fully implement and b) haven't had a strong use case yet. It would kind of be how the af:ff:ff:ff is currently used for routing table maintenance. You would need to consider how to handle these multicast addresses in the routing table. I suppose it could act as a sort of "alias" for nodes that want to subscribe to that channel. I'll keep this in mind as I work on updates to LL2. Thanks!
@paidforby, I did recognize a couple of things that should be addressed, concerning chat rooms.
First, if there are many users within the room, it consumes a lot of airtime, as messages has to be delivered to all members. Second, adding and maintaining rooms, might be complex, as rooms can be either served on application and/or protocol level.
How about adding a option to the LL2, to subscribe several users and rooms on one node? Then there would be a way to subscribe a user to a room. Whenever a user would link their phone to a node, the mesh would notify other nodes of the user and his/her rooms.
The problem stands as: how to implement this, without having to generate separate messages for advertising users subscribed to a new node.
Maybe, the room and user information could be passed within the payload. New users and rooms would be updated to the node database, when the messages are overheard within the mesh. Then, the destination nodes would be picked from the node database, according to the user information. Maybe a little bit too complicated, as the protocol should be as simple as possible. Any thoughts about this?