Message retention policy (disappearing messages)

[nplasterer]

We need a way to allow admins to set an expiration for messages in a group chat. Once that expiration is met messages should be deleted from all participants local database.

• Add new group metadata field for message expiration that takes an enum with different predefined intervals daily, weekly, monthly, 3 months, 6 months, yearly.
• Add a new permission policy for setting message expiration.
• Add a job that checks the message expiration and runs on a interval to clean up messages from the local database.

[nplasterer]

@covrter @saulmc do you see message retention policy being something that can be configured so any member can set/change the message expiration or an admin only feature? My gut is admin only but just want to make sure we are on the same page.

[saulmc]

Agreed. The idiomatic approach here is admin-only for groups, both members for 1:1.

[nplasterer]

@saulmc how do you feel about these predefined options or would you like more or less options?

• None
• 12 hrs
• 24 hrs
• 7 days
• 30 days
• 90 days
• 1 year

[covrter]

WhatsApp's default behavior is that all members can update the Disappearing time. Link

Anyone can turn disappearing messages on or off in group chats by default. But, group admins can change group settings to allow only admins to do this. Learn how to turn disappearing messages on or off in a group in this help article.

So I think, if possible, we'd want to build in flexibility for who can manage retention — in a small group of 3 or 10 friends, "everyone" of course makes sense; in a huge channel … less so.

[covrter]

@saulmc how do you feel about these predefined options or would you like more or less options?

• None
• 12 hrs
• 24 hrs
• 7 days
• 30 days
• 90 days
• 1 year

I'd suggest ...

• adding some Tiny windows to support the "realtime secrets" use case: 10sec and 1min.
• 8h rather than 12h (just for more difference btwn 12/24)

FWIW I think of like 3 broad use cases here, altho of course they're squishy:

1. "message retention" — long window (30d+)
2. "a chat where you can speak your mind" — medium window (8h, 24h, 7d)
3. "realtime secret/sensitive chat" where "you had to be there" and messages regularly during the convo — tiny retention windows (minutes or seconds)

[nplasterer]

@covrter I saw in some mocks that you had a box for custom retention times. In that case I wonder if the database field should be a Long. 🤔 and the enum should just be something we use programmatically. So that we can in the future extend this with custom content types cc @mchenani

[mchenani]

My suggestion is to use a long value based on seconds, with a minimum limit (e.g., 10 seconds). We can leave it up to the integrators or clients to decide how they want to present the options to their users—such as daily, weekly, or in hours. They would then pass this value in seconds to the SDK. This approach provides flexibility to the integrators rather than imposing predefined boundaries.
@nplasterer @saulmc

[nplasterer]

That sounds good. On the SDK level in the future we may impose some defaults just to help with ease of development but I think this makes sense for the backend.

[saulmc]

My suggestion is to use a long value based on seconds, with a minimum limit (e.g., 10 seconds). We can leave it up to the integrators or clients to decide how they want to present the options to their users—such as daily, weekly, or in hours. They would then pass this value in seconds to the SDK. This approach provides flexibility to the integrators rather than imposing predefined boundaries. @nplasterer @saulmc

Would a Long value simplify things for integrators, because they'd just need to convert a timestamp instead of conform to a specific set of values? Or does it make things harder for the "out of the box" integrator who doesn't want to support anything custom?

Maybe @alexrisch or @thierryskoda have a perspective on which would be easier to work with?

[thierryskoda]

I'm all good with working with seconds. It's very common with all libraries that support that kind of property. I would even say that It's more common to work with millisecond (ms).

[alexrisch]

@nplasterer @mchenani is this metadata being set for DMs as well?
At least making sure it's available there from the SDK perspective since that's most of our current user cases

[nplasterer]

Yep! good call out. It will be set for both but we will just need to expose it at the SDK level on dms (which we don't do for other metadata at the moment)