Message Deletion #67

New Issue

delvh · 2020-09-29T09:11:58+02:00

delvh commented

2020-09-29 09:11:58 +02:00

A critical part of every messenger is the ability to delete messages on demand.
Currently, only local deletion is supported.

However, complete deletion should also be supported: Necessary actions are

An Instant inside Message marking the deletion date
An Instant inside User storing the last known time a message has been deleted
the normal procedure of informing the users contacts also has to be performed.
Sending the user currently trying to login the complete set of foreign messages he currently should have (where he is the recipient), if a message deletion occurred -> Let him himself rebuild his message hierarchy.

A critical part of every messenger is the ability to delete messages on demand. Currently, only local deletion is supported. However, complete deletion should also be supported: Necessary actions are - [ ] An `Instant` inside `Message` marking the deletion date - [ ] An `Instant` inside `User` storing the last known time a message has been deleted - [ ] the normal procedure of informing the users contacts also has to be performed. - [ ] Sending the user currently trying to login the complete set of foreign messages he currently should have (where he is the recipient), if a message deletion occurred -> Let him himself rebuild his message hierarchy.

delvh added this to the v0.3-beta milestone 2020-09-29 09:11:58 +02:00

delvh added the

client

server

L

labels 2020-09-29 09:11:58 +02:00

delvh self-assigned this 2020-09-29 09:11:58 +02:00

kske commented

2020-09-29 09:18:25 +02:00

With database, you mean a database table?

I think we could solve this by introducing a boolean deleted to the Message entity. By using the timestamp of the user's last login, he can be notified of the message he must remove from his LocalDB.

With database, you mean a database table? I think we could solve this by introducing a boolean `deleted` to the `Message` entity. By using the timestamp of the user's last login, he can be notified of the message he must remove from his `LocalDB`.

delvh commented

2020-09-29 10:36:52 +02:00

@kske

With database, you mean a database table?

I think we could solve this by introducing a boolean deleted to the Message entity. By using the timestamp of the user's last login, he can be notified of the message he must remove from his LocalDB.

As you should know by now, I'll always confuse database with database table. I doubt I'll ever learn to do it right.

The problem I see with your approach is that we can then not tell when a message really can be deleted, as we have no way of knowing if every member of a group has received this Deletion update.
For P2P chats, this approach is feasible.

@kske >With database, you mean a database table? > >I think we could solve this by introducing a boolean `deleted` to the `Message` entity. By using the timestamp of the user's last login, he can be notified of the message he must remove from his `LocalDB`. As you should know by now, I'll always confuse database with database table. I doubt I'll ever learn to do it right. The problem I see with your approach is that we can then not tell when a message really can be deleted, as we have no way of knowing if every member of a group has received this Deletion update. For P2P chats, this approach is feasible.

kske commented

2020-09-29 11:41:19 +02:00

@kske

With database, you mean a database table?

I think we could solve this by introducing a boolean deleted to the Message entity. By using the timestamp of the user's last login, he can be notified of the message he must remove from his LocalDB.

As you should know by now, I'll always confuse database with database table. I doubt I'll ever learn to do it right.

The problem I see with your approach is that we can then not tell when a message really can be deleted, as we have no way of knowing if every member of a group has received this Deletion update.
For P2P chats, this approach is feasible.

A group message can be deleted when every member of the group has received the deletion request. This is the case, when every group member has logged in after the deletion request has been sent.

This means that we have to include a deletion timestamp, which is true for regular chats as well.

When you speak about deletion, do you mean actual deletion from the messages table, or just marking the message as deleted? In the latter case, this process could be simplified.

> @kske > > >With database, you mean a database table? > > > >I think we could solve this by introducing a boolean `deleted` to the `Message` entity. By using the timestamp of the user's last login, he can be notified of the message he must remove from his `LocalDB`. > > As you should know by now, I'll always confuse database with database table. I doubt I'll ever learn to do it right. > > The problem I see with your approach is that we can then not tell when a message really can be deleted, as we have no way of knowing if every member of a group has received this Deletion update. > For P2P chats, this approach is feasible. A group message can be deleted when every member of the group has received the deletion request. This is the case, when every group member has logged in after the deletion request has been sent. This means that we have to include a deletion timestamp, which is true for regular chats as well. When you speak about deletion, do you mean actual deletion from the `messages` table, or just marking the message as deleted? In the latter case, this process could be simplified.

kske commented

2020-09-30 08:17:31 +02:00

As discussed, the whole idea collapses when considering muliple local databases which have to be updated separately.

We might look into this in the future, however the implementation is a considerable amount of work. As this is not a very important feature (local deletion is still possible thanks to #70), I suggest to postpone this.

As discussed, the whole idea collapses when considering muliple local databases which have to be updated separately. We might look into this in the future, however the implementation is a considerable amount of work. As this is not a very important feature (local deletion is still possible thanks to #70), I suggest to postpone this.

kske removed this from the v0.3-beta milestone 2020-09-30 08:17:44 +02:00

delvh commented

2020-09-30 13:23:27 +02:00

Agreed, we can postpone it, but that does not mean deleting the issue either, I'd argue.

kske commented

2020-09-30 14:34:26 +02:00

Agreed, we can postpone it, but that does not mean deleting the issue either, I'd argue.

Thats why I removed it from the milestone. It can be added to a future milestone later on.

> Agreed, we can postpone it, but that does not mean deleting the issue either, I'd argue. Thats why I removed it from the milestone. It can be added to a future milestone later on.

delvh referenced this issue

2020-10-05 21:08:57 +02:00

Messages with Built-in Deletion Timer #81

delvh removed their assignment 2020-10-05 21:15:03 +02:00

delvh referenced this issue

2020-10-06 09:52:53 +02:00

Chat Deletion and Contact Removal #82

kske referenced this issue

2020-10-06 11:18:48 +02:00

Chat Deletion and Contact Removal #82

kske added a new dependency 2020-10-07 14:39:20 +02:00

#82 Chat Deletion and Contact Removal

delvh commented

2020-10-16 23:28:52 +02:00

As discussed, the whole idea collapses when considering muliple local databases which have to be updated separately.

We might look into this in the future, however the implementation is a considerable amount of work. As this is not a very important feature (local deletion is still possible thanks to #70), I suggest to postpone this.

As you might have seen in #97, I have found an efficient solution to the LocalDB problem. Hence, it no longer is unsolveable to delete a message entirely (or better to mark it as deleted).

The best part is: The biggest workload has already been done and can just be copied:
57e85f56e9 has removed any server side message deletion implemented so far and can just be reimplemented (except for a few minor changes).

> As discussed, the whole idea collapses when considering muliple local databases which have to be updated separately. > > We might look into this in the future, however the implementation is a considerable amount of work. As this is not a very important feature (local deletion is still possible thanks to #70), I suggest to postpone this. As you might have seen in #97, I have found an efficient solution to the LocalDB problem. Hence, it no longer is unsolveable to delete a message entirely (or better to mark it as deleted). The best part is: The biggest workload has already been done and can just be copied: 57e85f56e9 has removed any server side message deletion implemented so far and can just be reimplemented (except for a few minor changes).

delvh added this to the v0.3-beta milestone 2020-10-16 23:29:41 +02:00

delvh added a new dependency 2020-10-18 12:13:02 +02:00

#101 Message Editing

delvh removed a dependency 2020-10-19 18:19:16 +02:00

#82 Chat Deletion and Contact Removal

This repo is archived. You cannot comment on issues.