I also thought that this information is stored somewhere in Nakama.
@vladmustiata It is stored in Nakama but the preferences are not persisted by themselves. The server maintains chat history (optionally) and the streams are held in-memory when sockets are connected to the chat channels.
Does somehow ‘joining’ here means connecting to the socket to receive messages from that channel?
Yes, when a user opens a socket it does not implicitly mean they’ve joined any chat channels. They can choose to join chat channels or you can programmatically connect them to one or more of the chat channels but it’s explicit rather than implicit. This keeps the design flexible to what the user is actually interested in and makes it more flexible to different types of games. For example in a realtime multiplayer game the player might leave the chat channels when they’re in game to optimize bandwidth for important data messages, etc.
In this case, this means that the user never really ‘joins’ a channel – and it’s only a temporary connection, as long as he is on that channel & online?
I don’t know what you mean by “never really joins a chat channel” the user must of course join the chat channel to receive messages which are broadcast by other users onto it. They must also join it to send chat messages on it. This is why its referred to as joining a chat channel in our docs:
I thought that when you join a channel, this will be equal as starting a conversation in whatsapp or other messaging apps.
Yes, this is exactly what happens. You start a chat channel with one user (direct message), or to a group, or to a chat room and you will receive chat history when on or off the socket as well as can send and receive live chat messages in realtime. Have a look at the docs here:
I think what you might really be looking for is some kind of chat room manifest so that when the user starts the app they can see which list of chat channels they might have unread messages from. To implement this you’d just store a storage object for the user with the chat channels they’re “subscribed” on.
That way at app start you’d just fetch that storage object and programmatically connect the socket and join those channels for live messages. You can also fetch chat history for all those channels as well if you want and/or use the cacheable cursor to determine how many messages are unread for each channel.
You could even update the channel list for the user with an after hook that would do it automatically when the player joins the chat channel for the first time if you want.
I think the server covers all you’d need to implement Whatsapp as a messaging app (without the end to end encryption of course). The game server is authoritative over the chat messages rather than the end device like in Whatsapp.