Evaluating the MQTT protocol as a chat service to satisfy 1-1, 1-n, n-n communications for clients that may have limited connectivity.
The current design is for every client to by default subscribe to a channel based on their unique id,
e.g. 'users/9932947'. Messages (payload: JSON) published to this channel would contain a new randomly generated topic, e.g. 'conversations/2938475', for the conversation to continue.
This would allow for 1-1, 1-n, and n-n communications. And, it would mean the first message sent would start the 'conversation'. New conversations could be started with the same recipient list by initializing a new message. (I'm assuming plugins could handle multiple recipients listed in the payload, and the logic handling the 1-1,1-n,n-n conversation would happen client side)
I then face the reality, in pub/sub paradigm, that if user 1234 sends a message to user 5678, but user 5678 is not subscribed yet, then the message is lost, which, in some cases, would be bad. Using the 'retain' flag is not ideal, as more than one message may be sent.
So, once a subscriber receives a message, the logic flow would then dictate that the recipient(s) subscribe to the new topic identified in the payload. I'm probably breaking the pub/sub paradigm or maybe I'm missing something when it comes to dynamic topics and message expiration.
Knowing my broker/queue system could consume from my contact database, could persistence sessions be automatically created for users and those user be subscribed to these randomly generated topics/conversations? Is this a bad design? Any issues with scaling?
