Delete message on server will remain in the IOS App

[HuguesDug]

Steps to reproduce

1. In a conversation, create a chat message.
2. View it on the IOS client
3. Close the App
4. Delete the message on the server (from the SQL database)
5. Reopen the App
6. Message is still there

Expected behaviour

When reopening the app, or reopening a conversation, history of the chat messages should be updated, so deleted/modified messages on server side are removed. In the IOS version, the local cache is used and not checked against actual server data. It works correctly on the web client and on the Android chat client. When a conversation is opened (or app relauched), the local cache is cleared and updated with current server data. A modified or deleted message appear as it should.

Actual behaviour

A none existing message is still shown, where it should not.

Device information

Device: iPhone 6

iOS version: 12

Talk version: All released until the most recent one.

Server information

Nextcloud version: 24.0.3 (but was the same on previous versions). It works on Android and web versions. It is related to startup management in the android App.

Talk version: 14.0.3

Custom Signaling server configured: not relevant,

Custom TURN server configured: yes

Custom STUN server configured: yes

Server log (data/nextcloud.log)

Not relevant

[SystemKeeper]

4. Delete the message on the server (from the SQL database)

Hey @HuguesDug, just to be sure here, you're really deleting messages directly in the database and not using the delete message functionality from talk, right? If that is the case, talk-ios behaves as intended, from my point of view. The whole point of having the messages cached locally is to not have to synchronize the whole message history again and again. If a message is deleted within talk a hidden message is sent to the devices to let them know that there is a message, that should be deleted - this is not the case when you manipulate the database.

[HuguesDug]

Hello,

Yes, your remark is correct : directly removing from database without going throught the API.

Though, Android App or Web version do a resync of the cache when you open the App or open a conversation, what, in my perspective, makes fully sense. In this way, you perfectly warranty the data on the device.

Just relying on the local cache leave alive any "problem" that has occured regarding sync or processing messages.

I discovered this as I implemented a TTL on read messages with a script that runs on the my sql database. Deleted messages goes away like a charm on WEB and Android... but not on IOS. So, behavior of the various implementation is clearly different.

[SystemKeeper]

So if TTL is something you want to use, there will be support for it in an upcoming version, see https://github.com/nextcloud/spreed/issues/7359

There's also some discussion about lifiting the 6h limit for message deletion, you can find the discussion at https://github.com/nextcloud/spreed/issues/7134

Deleted messages goes away like a charm on WEB and Android... but not on IOS. So, behavior of the various implementation is clearly different.

Well, indeed the behavior is different, but it isn't wrong either. The web part of talk only caches messages in the current session, so reloading the page, will reload the messages. On Android there's no offline support, so there's no real caching (never used the android app, just judging from the tickets. There's offline support planned at some point, though: https://github.com/nextcloud/talk-android/issues/217). So for your case you're relying on something that's not intended to work that way to be honest.

[HuguesDug]

I fear the TTL will not suite my need. I want to delete only read messages after a period, unread can stay on the server for unlimited period of time.

As far as I could read from TTL concept, all the messages will expire after a period of time, being read of not. Reason why I tried to work around the problem.

Any hint ?

[SystemKeeper]

Any hint ?

Not really. What you're trying to achieve is not possible in the current implementation and I don't think that this will change (just my personal opinion). I also can see some problems: What happens if your users turn off read receipts in talk? Suddenly all messages are marked as read and will vanish?!

Without knowing the details of your use case, I still think TTL will be the closest you can get at this moment.

[SystemKeeper]

As discussed with @Ivansss there are no plans to change the current behaviour.