Automatic removal of messages based on a time (or number of messages per thread?)

[FredericJacobs]

It's technically really easy to implement since we're already using a similar database index to sort messages in the MessagesViewController.

Ephemerality ftw

[FredericJacobs]

Wondering if this should be time-based or depending on number of interactions with a given contact.

[corbett]

how is this done on android? we have a big philosopher for fewer settings.
I would lean to have a timebased setting that was either on or off or none
at all, without minute configuration options for now. it could also be
ratchet based (that is keep the same number of messages on chains that we
keep around) which to me would make the msot sense.

On Wed, Dec 31, 2014 at 2:18 PM, Frederic Jacobs notifications@github.com
wrote:

Wondering if this should be time-based or depending on number of
interactions with a given contact.

—
Reply to this email directly or view it on GitHub
#254 (comment)
.

Dr. Corbett Moran
Rockets @ http://www.spacex.com
Physics @ http://www.ICS.uzh.ch http://www.ICS.uzh.ch
Dev @ http://circleof6app.com
Dev @ https://whispersystems.org
www.christinecorbettmoran.com

[FredericJacobs]

I put this on 2.1 milestone. The ratchet is encapsulated and I wouldn't use that. A time based setting is hard to enforce if the user doesn't open the app.

My preference leans towards a slider that lets you define how many messages you want to keep max per conversation. Default value (middle of the slider) would be 50 or something.

[corbett]

I think we should sync up with android and have the same settings available
on both. it makes sense re:encapsulation.

On Wed, Dec 31, 2014 at 4:34 PM, Frederic Jacobs notifications@github.com
wrote:

I put this on 2.1 milestone. The ratchet is encapsulated and I wouldn't
use that. A time based setting is hard to enforce if the user doesn't open
the app.

My preference leans towards a slider that lets you define how many
messages you want to keep max per conversation. Default value (middle of
the slider) would be 50 or something.

—
Reply to this email directly or view it on GitHub
#254 (comment)
.

Dr. Corbett Moran
Rockets @ http://www.spacex.com
Physics @ http://www.ICS.uzh.ch http://www.ICS.uzh.ch
Dev @ http://circleof6app.com
Dev @ https://whispersystems.org
www.christinecorbettmoran.com

[FredericJacobs]

Screenshot from the Android setting

[corbett]

cool, let's do that then (but egads so many settings)

On Fri, Jan 2, 2015 at 9:52 PM, Frederic Jacobs notifications@github.com
wrote:

Screenshot from the Android setting
[image: image1]
https://cloud.githubusercontent.com/assets/400296/5600017/0f9ab654-92d2-11e4-9f4f-744b6bb15729.JPG

—
Reply to this email directly or view it on GitHub
#254 (comment)
.

Dr. Corbett Moran
Rockets @ http://www.spacex.com
Physics @ http://www.ICS.uzh.ch http://www.ICS.uzh.ch
Dev @ http://circleof6app.com
Dev @ https://whispersystems.org
www.christinecorbettmoran.com

[abolishme]

Clarifying question @corbett and @FredericJacobs, please mention me in your answer: would the conversation history still be available on the server side, and just the local copies deleted? So you'd have a pull to refresh style "loading more messages" UI like most other clients? Or would they just be gone forever?

[corbett]

@abolishme conversation history is never available server side. the server
does queue up undelivered messages but once they are delivered the server
doesn't know or doesn't care. they would be gone forever.

On Fri, Feb 27, 2015 at 1:46 PM, Tyler Reinhard notifications@github.com
wrote:

Clarifying question @corbett https://github.com/corbett and
@FredericJacobs https://github.com/FredericJacobs, please mention me in
your answer: would the conversation history still be available on the
server side, and just the local copies deleted? So you'd have a pull to
refresh style "loading more messages" UI like most other clients? Or would
they just be gone forever?

—
Reply to this email directly or view it on GitHub
#254 (comment)
.

Dr. Corbett Moran
Physics @ http://www.tapir.caltech.edu http://www.ICS.uzh.ch
Dev @ http://circleof6app.com
Dev @ https://whispersystems.org
www.christinecorbettmoran.com

[abolishme]

One concern I have @FredericJacobs and @corbett: if someone texted me something I want to save, then they send me 200 texts tomorrow and the max-message X was set to 200, i would lose it?

If that's the case, we should make it possible to pin/save messages that won't disappear with the rest (snapchat does this) ... i'll add that to my brainstorm list.

[FredericJacobs]

@abolishme: Keep it simple. We already have enough complexity with archiving and deleting. Pinning is really not needed.

[Baigle-zz]

There wouldn't be an easy and secure way to save messages like that without something similar to #738.
Legality (local to user) and threat of death aside, these are all just ways of hiding/ protecting past conversations that the protocol tries to protect so desperately in transit.

How well would this cooperate on its own, or with existing anonymity systems where users really are in a very desperate situation regarding communications?

[roadkillazpartybird]

I agree it should mirror the android 'Delete old messages' option as seen in the above picture. Then there won't be any confusion! :)

Can't wait to see this implemented in iOS.

Edit2: Since the introduction of timed messages this issue is essentially solved. Congratulations!

[ghost]

This is an essential, yet missing feature: inactivity-based deletion. The best way to analogize this would be to talk about it like Google's inactive account manager. After a certain period of time of the app/device not being used, a message would then automatically be deleted. Otherwise, if the person continues use of app, no auto delete for older messages. The importance of this time-based deletion policy cannot be overstated for unapproved searches and/or seizures of devices for local attacks.

[Wikinaut]

👍 I also would like to see the "Delete old messages" option (which is in the Android version) in the iOS version.

[tomj]

While this issue is a feature request and so should be closed regardless, I can additionally confirm this feature has been implemented and shipped to production in 2.38.1.2 in the form of "Disappearing messages".

To use feature: click on a chat in the chats list, click on "Tap here for settings" next to contact avatar on UINavigationBar, toggle the "Disappearing Messages" switch and adjust duration for message lifetime using the revealed slider.

An announcement of the feature was made on the blog on 11 Oct 2016 and there is a Signal support page with slightly more detailed usage instructions.

[awaitlink]

@tomj However please note that the specific feature shown in #254 (comment) is not implemented in iOS.

I'm not sure if the Conversation trimming based on message count is available on Android but surely it's not available on iOS, while Disappearing messages is available on all platforms.

Conversation trimming based on message count != Disappearing messages.

[tomj]

@u32i64 thanks for the heads up - my closure recommendation was based on the current issue title but I get what you're saying about that comment.

Regardless of whether it has been shipped to prod, this issue is a feature request and should be recognised as such in some form, and closed/transferred to a listing of feature requests.

From there any further discussion can ensue in a separate but related thread. Here's a placeholder for now to keep track of any further discussion you want to throw out while the upstream krew work out a strategy to pipeline feature request issues to working feature requests and clear out this backlog.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[obinoby]

My Signal database is eating 11GB of valuable space in my iPhone. This is the biggest data consumer in my phone.
I'd love this feature to be implemented in iOS as it is on Android.
The Disappearing messages feature is not the same as it apply to all members of a conversation. I just want the ability to save space on my device only.
This is a needed feature that is essential to some of us. If it can’t be done in the background then maybe it can be done when the app is in use.
I’m even ok with a button in the settings to manually trigger a cleanup.

[ReallyReally17]

How is this issue closed?

How can you justify an ever increasing consumption of space?