I am building an application that, among other things, uses the chat function of the Video SDK. Now I would really like to be able to reply to messages and create a thread like in Zoom. I know the Meeting SDK has the IsComment and IsThread, as well as GetThreadID, in the chat message info. As far as I can find, the Video SDK does not have a similar system of threads and comments for replying to messages.
How can one make a repy system like the one in Zoom using the video SDK? Am I missing something?
Thanks for the help in advance.
Hi @noahviktorschenk The Video SDK does not have a IM Chat functionality like the Meeting SDK. All chats are in-session. However, you could implement this functionality using the message ids provided in the ChatMessage object of a received message. From there, you can implement threads with unique IDs and persist message by saving them in your environment to a DB.
Hey @ticorrian.heard, thanks for the reply. Correct me if I am wrong, but arenât the chat function in Zoom meetings also only in-session?
Also, could you quickly explain to me the difference between IM Chat and âregularâ chat in Zoom? I have worked with Zoomâs SDKs for over a year, and I have never been able to figure out the difference.
I am not looking for persistent messages, just a way to reply to specific messages in the âgeneral â chat. So just to clarify, there are no built-in ways of replying to messages? I would have to implement my own solution with a DB to save them to be able to add thread IDs so people can reply, or can I somehow attach metadata to messages so I donât have to set up a DB?
Happy to clarify @noahviktorschenk We have in-meeting chats for Video and Meeting SDK. The out-of-meeting(IM) Chats offered in the Zoom platform is a client specific chat option and can be used via REST API as well.
The reply functionality can be implemented by creating a unique thread id for each message. If a user would like to reply to that message, you can assign that thread id to the reply message and place all messages tied to that thread id in the same column in your UI.
Ah, perfect, makes sense. Thank you for the clarification @ticorrian.heard.
Yeah, okay, I can see the system, but this would require me to connect a DB or something like that, to assign the thread IDs, correct? The video SDK does not have any way of setting IDs or anything, so I would have to store that separately for it to show up for everyone. Or am I missing something?
Hey @ticorrian.heard, just to clarify. For me to add a reply option, so users can reply to messages in the meeting, I would have to save every message in an external database. Then, when someone wants to reply to a message, I generate a thread ID and add that to the DB record of the message they want to reply to. Then, when I save the new message, I set the thread ID of that message to the same as the previous message. Then, when I am displaying messages, I would fetch them from the DB to get their thread ID and render them accordingly.
So, in short, I wouldnât need the video SDKs chat function at all, since I would have to save and read everything from and to a database. Am I understanding this correctly?
I just want to make sure there is no way of implementing a reply option before I go and tear the entire video SDK chat functionality out and replace it with my own solution.
Hi Noah, you donât necessarily need an external database. Only if you want the messages to persist outside of the session. If not, you can implement this without the DB and tie each message to the thread id generated for the ârootâ message. You would send and receive these messages use the send() function and message received events of the SDK, respectively.
Hey @ticorrian.heard, thanks for the clarification, but Iâm still not seeing how this would work without a DB.
The send() function only takes message content (string) and userId as parameters. Thereâs no way to attach metadata like a thread ID that other participants would receive. So even if I generate thread IDs locally, other users wouldnât know which messages belong to which threads.
The only solution I can think of is to encode the thread ID directly into the message content (e.g., JSON) and have all clients parse it to reconstruct the threading. Is that what youâre suggesting? Or is there a way to attach metadata to messages that Iâm missing in the SDK?
Just want to make sure Iâm not overlooking any SDK features.
Ah I see @noahviktorschenk if you want to keep the same thread ID between clients, that would require some form of a DB or messaging between clients. You could also generate the thread ID on the senders devices and communicate it to other clients using the Video SDK command channel messaging. There are definitely many ways of achieving this feature for sure. These two, seem like an easier approach in my opinion.