3

I am building a MQTT based private messaging application using Eclipse Paho. I am a beginner in MQTT so need to understand implications of Topic architecture.

If user A has to send a message to user B:

  1. make user A subscribe to topic A and user B to topic B. So anyone messaging to B has to publish in topic B (the payload contains the sender details)
  2. make user A subscribe to A/# and B to B/#. So B messaging to A will publish to topic A/B

I want to know the recommended topic subscribing in private messaging considering implementation of other features like

  1. Last Seen
  2. Online
  3. Delivered
  4. Read

Please suggest ways (topic, pub and sub) to implement above features. For example after a client has connected to a broker, it will send a retained message to the topic A/status with the payload “online“.

hardillb
  • 54,545
  • 11
  • 67
  • 105
Ankit Nayan
  • 363
  • 7
  • 18

2 Answers2

1

first thing first:

There is no private messaging in the MQTT protocol, it all is based on a publish-subscription data exchange mechanism, If nodeA wants some others to know about its messages, then nodeA must publish on a defined topic that data, there is nothing that can constrain that a second nodeB or nodeC can get that information too, why? because of the loose coupled architecture... nodeA doesnt even need to know who is getting the message

so the node publishing data can have 0... or n subscribers to that topic.

enter image description here

as I said before, Mqtt is protocol where the node that publish data doesn't need to know anything about the node(s) that are subscribed to that.

in a chat Application is exactly the opposite, PartnerA chatting to PartnerB means PartnerA needs to know how to a final (and maybe only) destination of the msgs... Mqtt is not defined for that

schankam
  • 10,778
  • 2
  • 15
  • 26
ΦXocę 웃 Пepeúpa ツ
  • 47,427
  • 17
  • 69
  • 97
  • So pub-sub is not meant to be made for private chatting? Though FB Messenger seems to work on MQTT for messaging – Ankit Nayan Jun 28 '17 at 07:15
  • Write your own broker then you can do anything you want with MQTT messages (i.e. FB Messenger). – Roger Jun 28 '17 at 23:21
  • 1
    To expand on this: MQTT is just a protocol, Facebook wrote their own internal broker which passes payloads that (presumably) contain further routing data which allows for private messaging. To create this functionality you most likely would need to do the same thing. – blp Jun 29 '17 at 05:51
  • 1
    Yes I guess but I don't think that pub-sub is not meant to be for IM as stated by @Φxocę-웃-Пepeúpa-ツ. I needed to figure out the things to keep in mind for that. I guess there is not much info around that in internet. – Ankit Nayan Jun 29 '17 at 10:25
  • HiveMQ has the ability to support Access Control Lists (ACL). Also, I believe there are plugins for Mosquitto that support ACL. If you are building an IM app then after a few users, handling ACLs will get really cumbersome. I suppose you could do /MyIM/Private/User/{username}/ as a topic and make the ACL so that everyone ('world') is allowed to publish to it and ONLY the matching username is allowed to subscribe to it. But it will be the management of the ACLs that will be a lot of work. – Roger Jun 29 '17 at 16:26
1

I wouldn't do this with MQTT but if I had to I would use access control lists. Mosquitto (and probably other brokers) allows a user to have publish but not subscribe access to a topic. This allows you to effectively create a private message infrastructure as follows.

Clients A and B are authorized to publish to topic clientc but not subscribe to it. (Write but not Read/Write access)

Client C is authorized to subscribe to clientc. (Read access)

If Client A publishes a message to clientc then Client C receives it but Client B does not. And, of course, vice versa.

There are significant weaknesses to this approach (it assumes all clients are online at the same time, etc.) but it is a private messaging structure that can use a standard MQTT broker. The rest of the features could then be implemented on top of this. Also, you could further toughen it up by PGP encrypting the messages.

blp
  • 578
  • 1
  • 5
  • 9