Which is the recommended Topic structure in MQTT for private messaging?

2
votes

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“.

2
chatmqttpublish-subscribemessagebroker
recommended topic subscribing in private messaging??? what do you mean with that? – ΦXocę 웃 Пepeúpa ツ
I gave 2 options where subscribing pattern is different to get/send messages form A to B. I need recommended subscribing patterns for private chatting like FB messenger. – Ankit Nayan
you could define a weird topic that is only known between A and B, but then you are using the protocol wrongly.... – ΦXocę 웃 Пepeúpa ツ
This sounds awfully like a homework assignment? – hardillb

2 Answers

1
votes

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.

1
votes

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