0

Building an instant chat app (native IOS and web). Exploring whether to use XMPP or MQTT as application protocols. Seemingly I can't have users editing old messages on XMPP. Can messages be edited on MQTT?

Example: I want to implement "Edit Message" like Slack offers, but upon clicking "(edited)" to allow the user to see the different versions of the message and their timestamps (like the edit history for comments you find in Facebook), enabling an "audit trail" of the conversation.

Follow-up: As it seems this can only be achieved through a "hack", would it be better to get the hack done on XMPP or MQTT or some other protocol/websockets/JSON, etc?

Pat
  • 443
  • 6
  • 13
  • What exactly do you mean by edit the message on the broker? – hardillb Jul 21 '17 at 17:48
  • Please provide [Minimal, Complete, and Verifiable](https://stackoverflow.com/help/mcve) example. This will allow us to assist you with your question. – gorkem Jul 21 '17 at 20:07

2 Answers2

0

Once a MQTT message is published to the broker the publishing client has no more control over that message at all.

Most brokers will not allow you to edit the message either as they will just forward the message instantly to all clients subscribed to the relevant topics and queue the message for any offline clients with persistent subscriptions.

The only exception may be the mosca broker that has a call back for when messages reach the broker, but this would not allow a user to edit a message, only the system to possibly update the payload in the instant before it was forwarded to the subscribed clients.

hardillb
  • 54,545
  • 11
  • 67
  • 105
  • Thanks @hardillb. So, based on your experience, what would you suggest exploring to implement "edit" (like Slack offers)? – Pat Jul 22 '17 at 12:24
  • You wouldn't implement it that way any way. Messages should include meta data to cover this sort of thing. – hardillb Jul 22 '17 at 16:11
0

Hardlib's advice is correct, editing messages in this way is not supported by most MQTT implementations and to implement it would break the loose coupling between publisher and subscriber that is the virtue of MQTT. In other words this should be implemented at a higher level or through other means.

That said, if I understand editing to mean the ability to change what the broker forwards to clients that were not online during the initial publication, you could implement this with retained messages. Consider this:

  1. Client A is subscribed to topic clientb/# and Client B is subscribed to topic clienta/#.

  2. Client A publishes a message to clienta/(unique message id) while Client B is not actively connected. The broker retains the message.

  3. Client A decides to edit the message so (through some interface you devise) they publish an amended message to clienta/(unique message id) which replaces the message and, from a subscribers perspective, edits what is there.

  4. Client B receives the amended message when they come online and (as long as there isn't a persistent session or something like that) has no knowledge of the change.

From this example you can probably tell why this is a bad idea as the server would retain every single message in a different topic and would likely need regular pruning... not mention that it would make a mess out of timestamps and require all sorts of other work arounds. However, if there is some reason that you have to implement it this way you could hack something usable together.

blp
  • 578
  • 1
  • 5
  • 9
  • Thanks @blp. Appreciate the example. I've just edited the question for clarity and the intention is indeed to keep the "edit history" and their timestamps enabling an "audit trail" of the conversation. Given this is to be achieved through a work around, would you say we better give a go in MQTT or XMPP? – Pat Jul 25 '17 at 09:15
  • or some other protocol/websockets/JSON, etc? – Pat Jul 25 '17 at 12:37
  • I think the issue is that you could achieve all of these things in all of those ways, it isn't really dependent on the protocol as to provide that kind of audit trail you are probably going to running a back-end database... So your larger environment matters more to your protocol choice than the edit concern. So, for example, if there are energy constraints or network reliability issues I would use MQTT over HTTP. – blp Jul 27 '17 at 22:41
  • Also this might be of help: https://stackoverflow.com/a/7131624/7746400 – blp Jul 27 '17 at 22:45