How can I let user know he haven't read message?

Objective

How can I let user know he haven't read message?

Detailed work content

I've asked to GPT what I need and how to deal with it.
Note

I updated my erd. If you want, just check it out!

Even just reading our conversations wold be awesome to think of what's important and how we can deal with it.

How to check if user haven't read messages yet.

At the beginning, I was discussing sharing same message with other devices.

ME

let's assume I'm making chatting application. User might want to access chatting application with multiple devices. For instance, If user A log in chatting app with smartphone, he also want to log in chatting app with computer.

If user chat with computer, user's smartphone will get the same message from user A. To cut it short, what devices they use simultaneously, messages must be shared.

I mean, how can I let server know User don't log in twice . Also, How can I share same message to another device?

ChatGPT

To implement this feature, it's crucial to distinguish between users and devices. A user account can have multiple associated devices, and these devices should all share the same user context.

Here is a high-level overview of how you can design this:

Authentication When a user logs in from a device, the server should authenticate the user (usually with a username and password). On successful authentication, the server will generate a unique access token (JWT or similar) tied to that user account and return it to the device. This token should contain information about the user, not the device.

Device Association After a successful login, the device should be registered or associated with the user account in your backend system. This device association might include information like a unique device ID, the type of device (e.g., Android, iOS, Web), and any necessary push notification tokens.

Server-Side Storage The server stores all chat messages. When a message is sent from a device, it goes to the server, which then stores the message and the associated user data.

Real-Time Data Sync When the server receives a message for a user, it needs to push that message to all devices associated with the user. The method for this will depend on your real-time communication system. If you're using WebSockets or similar technology, your server could keep a mapping of user-to-WebSocket connections and broadcast incoming messages to all associated connections. If you're using push notifications, your server could use the stored push tokens to send the message to all devices.

Handling Multiple Logins As for ensuring a user doesn't "log in twice", this isn't usually a concern in such systems. If a user logs in on a new device, this is typically treated as adding a new device to their account, not a duplicate login. If you want to limit the number of devices a user can be logged into, you could enforce this limit at the point of login by counting the number of associated devices in your database.

Message Synchronization When a new device logs into an account (or reconnects after being offline), it would fetch the recent chat history from the server to sync its local state with the current state of the conversation.

State Synchronization For features like read receipts or typing indicators, you can implement a system where each device reports its state to the server (e.g., "this message has been read" or "the user is currently typing"). The server then updates this status in the central data and pushes the updated status to all other devices.

This kind of system design requires careful planning and understanding of various technologies and techniques, including databases, real-time communication, and security. But with the right tools and architecture, it's entirely possible to create a chat app where a user can seamlessly move between devices.

Message Synchronization and State Syncronization? How can I make it happen?

Me

Message Synchronization and State Syncronization? How can I make it happen?

ChatGPT

Message Synchronization:

Server-Side Message Storage When a message is sent, it should be stored on the server, along with the information about who sent it, which conversation it belongs to, and when it was sent.
Fetching Recent Messages When a device logs in or reconnects, it should request the most recent messages for each conversation from the server. The server can then query the database for these messages and send them back to the client.
Message Delivery The server should also push new messages to all connected devices in real-time. This can be done using technologies like WebSockets, Server-Sent Events, or push notifications.
Message Ordering To ensure messages appear in the correct order, each message could have a timestamp or sequence number. The client can then sort the messages based on this value.

State Synchronization:

Tracking Read Receipts When a message is displayed on a device, the client should send a read receipt to the server. This receipt would include the ID of the message and the ID of the user who read it.
Updating Read Status The server would then update the read status of the message in the database, and broadcast this update to all other connected devices of the user.
Typing Indicators When a user starts or stops typing, the client should send a typing status update to the server, which then broadcasts this status to all other participants in the conversation.

In terms of the technology stack to implement these features, it can vary widely depending on your specific needs and constraints. On the server-side, you could use a technology like Node.js, Java, Python, or Ruby, along with a real-time communication library like Socket.IO for Node.js. For the database, a document-oriented database like MongoDB could be a good fit due to the flexible and nested nature of chat data, but a relational database like PostgreSQL or MySQL could also work.

On the client-side, you could use native technologies for Android and iOS if you're building mobile apps, along with something like React or Vue.js for a web app. For real-time communication, you can use WebSockets or a higher-level library like Socket.IO, along with push notification services provided by the mobile platforms.

Please note that designing and building a system like this is a significant undertaking that involves a lot of different components and technologies. If you're just starting, I would recommend learning more about these topics, starting with a simpler version of your application, and then incrementally adding features as you learn.

ReadReceipts table?

Me

Why do i need ReadReceipts?

ChatGPT

ReadReceipts table help you keep track of things whether user read the message or not. The purpose of the ReadReceipts table is to track which messages have been read by which users on which devices.

In this table, a row would be created each time a user reads a message on a device. The row would contain the ID of the user who read the message, the ID of the device they used to read it, the ID of the message they read, and the timestamp when they read it.

By looking at this table, you can determine:

Whether a particular message has been read and, if so, when and by whom.
Which messages a particular user has read and when they read them.
Which messages have been read on a particular device and when they were read.

This gives you the information you need to implement read receipts in your chat application. For example, if you wanted to display a checkmark next to each message once it has been read, you could check the ReadReceipts table for a row with the same message ID. If such a row exists, you would display the checkmark; if not, you would not display it.

Is this processs right?

Me

let me talk through ReadRecipts table again. If we assume there are User A and User B in chatting room AA, they can have a conversation together.

If user A is out and user B send message in chatting room AA, ReadReceips table will get the new row data. Actually regardless of absence of user A, ReadReceipts table will get row.

ChatGPT

The ReadReceipts table records when and by whom a message was read. Therefore, new rows should be added to this table when a user actually reads a message. If a user is not present in the chat room and does not read the message, there should be no entry in the ReadReceipts table for that user and message.

Here's how it would work in your example:

User A and User B are in chat room AA. They can send messages to each other.

User A leaves the chat room.

User B sends a new message in chat room AA.

At this point, User A has not read the message because they were not in the chat room when the message was sent. So, no new row should be added to the ReadReceipts table for User A and this message.

If User A later returns to chat room AA and reads the message, then you would add a new row to the ReadReceipts table with the user_id of User A, the message_id of the message, and the read_timestamp of when User A read the message.

The purpose of the ReadReceipts table is to keep track of which messages have been read by which users. If a user has not read a message, there should be no entry for that user and message in the ReadReceipts table.

Me

So, just in case user doesn't get message in the same chatting room although he is the member, I need to add the row in ReadRecipts table right?

ChatGPT

Not quite. The ReadReceipts table should only be updated when a user actually reads a message. If a user is a member of a chat room but does not read a new message (either because they are not currently in the room, or they are in the room but do not open or read the message), you would not add a new row for that user and message in the ReadReceipts table.

If you wish to keep track of all the unread messages for each user, you could handle it in a couple of ways:

Implicitly: By not having a row in the ReadReceipts table for a user and a message, you can infer that the user has not read that message. If you want to find all the unread messages for a user, you can query all messages in the rooms the user is part of that do not have a corresponding row in the ReadReceipts table.

Explicitly: You could add an UnreadMessages table where you insert a row every time a message is sent in a room where a user is a member, and remove the row when the user reads the message.

In most cases, the implicit approach should be sufficient and efficient. It minimizes the amount of data you need to store and handle, as you only add data when a user actually performs an action (reading a message).

Me

Then, how do we know whether user read the message or not?

ChatGPT

Whether a user has read a message or not is determined by the presence or absence of an entry in the ReadReceipts table for that user and message.

Here is a simple illustration:

When a message is sent in a chat room, no entries are immediately made in the ReadReceipts table. At this point, you can assume that the message is unread by all users.

When a user reads the message, you add a new entry in the ReadReceipts table with the user's ID, the message's ID, and the time the message was read.

To check if a user has read a message, you look for an entry in the ReadReceipts table with the user's ID and the message's ID. If such an entry exists, the user has read the message. If no such entry exists, the user has not read the message.

To get a list of all unread messages for a user, you can select all messages from the rooms the user is part of that do not have a corresponding entry in the ReadReceipts table for that user.

This allows you to accurately track which users have read which messages, and only store data when a user actually reads a message. Note that the user's client application or device must report to the server when they read a message in order for this to work accurately.

Me

I'm curious why you recommend me to insert data when user read rather then when user don't read it

ChatGPT

There are a few reasons why it's generally more efficient to insert rows in the ReadReceipts table when a message is read, rather than when it's not read:

Data Volume: In a large system, the number of unread messages can be very large, especially if a user is a member of many chat rooms or hasn't logged in for a while. Storing a record for every unread message for every user could result in a huge amount of data. On the other hand, storing a record only when a message is read usually results in less data, because users typically read only a subset of all possible messages.

Simplicity of Updates: When a message is read, you just need to insert a single row. If you were tracking unread messages, you would need to insert a row for each user every time a message is sent, and then delete those rows as each user reads the message. This is more complex and could result in more database operations, which can be slower.

Consistency of Information: If you track unread messages, there's a risk that a message might be marked as unread even after it's been read, if for some reason the database update failed or was delayed. If you track read messages, at worst a message might not be marked as read immediately after it's been read, but it will be marked eventually, which is typically a more acceptable delay.

Scalability and Performance: For large-scale systems, reducing the amount of data to handle and the number of database operations can significantly improve scalability and performance.

Remember, these are general guidelines and the best approach can depend on the specifics of your application. In some cases, it might make more sense to track unread messages, but in many situations, tracking read messages is a more efficient approach.

Is is possible to cancel message?

Me

Well, In Kakao talk, the chatting application, can withdraw message in five minutes. Is it possible to make it with NOSql?

ChatGPT

Yes, it's certainly possible to implement a message withdrawal or deletion feature in a system that uses a NoSQL database for storing messages. The specifics of how you implement it might depend on which NoSQL database you're using , but here's a general approach:

Add a 'status' field to your Messages You could add a field to your Messages table or document that indicates the status of the message. The status could be 'sent', 'deleted', 'withdrawn', or any other status you need.
Update the status when a message is withdrawn When a user chooses to withdraw a message within the allowed timeframe, you update the status field of the corresponding message in the database to 'withdrawn'.
Handle withdrawn messages in your application When displaying messages to users, your application should check the status field and handle 'withdrawn' messages appropriately. For instance, instead of displaying the content of the withdrawn message, you could display a notice like "This message has been withdrawn."
Propagation to all users After the message status is changed to 'withdrawn', this information needs to be propagated to all clients who have received the original message. Depending on your design, this could be done via WebSockets or any real-time communication protocol your application is using.

Note that this approach only marks the message as withdrawn and doesn't actually remove the message from the database. If you want to completely remove the message from the database, you would need to actually delete the corresponding record. However, be aware that deleting records might have other implications (for example, it might affect your ability to keep a complete log of all activity for debugging or auditing purposes). It may also be more complex if the database is distributed or sharded, as many NoSQL databases are.

thelovemsg / chatting_app