⏳ Expiring messages

[nickvergessen]

• [x] API
  • [x] Part 1: #7327
  • [x] Part 2:
    • #7508
    • #7571
• [ ] Web https://github.com/nextcloud/spreed/pull/7689
• [ ] iOS https://github.com/nextcloud/talk-ios/issues/853
• [ ] Android https://github.com/nextcloud/talk-android/issues/2281

[marcoambrosini]

Time to live -> expiring messages This is done on a per conversation basis and moderators only can set this

Options:

• 1hr minimum (due to technical limitation)
• Allow different options beyond that (maybe some quick settings and then a custom, fine tune option)

"Older messages were deleted" or some sort of info as first message in the message list

--

• [ ] Hide the feature when systemcron is not used
• [ ] Show info about module-depending features in the admin settings

[marcoambrosini]

Can this be changed once a conversation is created? If so let's say there's already a message history in the conversation and the moderator toggles expiring messages on. What would happen to the already present messages? cc @nickvergessen

[nickvergessen]

It would affect all existing messages and basically the next cron job would expire messages that are older than the set time? We would also document the TTL change with a system message so it's clear to all participants.

Being able to change it after creation is a must have as otherwise it's basically impossible to get it for one-to-one conversations (1. due to the flow, 2. due to the fact that you would need to get the other participant to also leave it and only then you could create it with TTL). Also I don't think we should artificially restirct the TTL to creation

[marcoambrosini]

Would it be possible to preserve the history before the TTL has been set? Like this

[nickvergessen]

That would require storing the TTL on a per message basis. Since it's not our database table and also the database table is quite big I'm not sure we can easily add a new DB column, but that would be possible in theory.

Is it like this in Signal and Telegram too?

[marcoambrosini]

It's like this in WA and Signal, telegram has secret chats and regular chats. We prefer the WA and Signal way, but if it's too much effort and we cannot preserve the history we'd just do it like telegram and have regular and secret chat, with the ability to set this only at the conversation creation stage.

[nickvergessen]

Hmm while adding a column for this we could then also add a column for meta data (to store the "silent sent" info). The question is how happy the server/comments people are if we bloat it up for talk specifics, but we can see

[vitormattos]

telegram has secret chats and regular chats.

Now Telegram also can expire messages in a not secret chat.

[nickvergessen]

Then all are aligned on the same situation.

So we need a new column on the oc_comments table and we directly add the expiration datetime stamp when posting the message.

We can then have a background job per room which deletes the message which reached their time

[HuguesDug]

Hello,

Would be great to have the option that user can opt for deleting only read messages that have reached the TTL, not all the messages.

[mahibi]

For the json message parameters of the "You set the message expiration to 1 hour" message i have the problem that the seconds are coded as number but not as string.

"messageParameters": {
    "actor": {
        "type": "user",
        "id": "marcel",
        "name": "Marcel"
    },
    "seconds": 3600
},

Until now the message parameters were always strings. So on android we expect a hash map of type string. Passing a number well result as "null" on android. Can this be changed on server side? @vitormattos @nickvergessen

[vitormattos]

What format you suggest? This is an interval

[nickvergessen]

Fixed with nextcloud/spreed#7771