Conversation settings changes (color, picture, name) in message history
BaeoMaltinsky opened this issue · 6 comments
See #47. Again, I want clarity about whether these are persistent features of the linear message history, and whether or not they expire like normal messages
Exploding messages settings feel like a separate category because they're security-related.
I think all other settings should cause a " changed the group " note to be left in the conversation history.
I don't think it should expire. Rationale: a disappearing messages timer only affects messages, not group metadata. The note in the conversation history isn't a message, it's a tracker for group metadata history, and so should be treated more like the metadata.
If anyone sees a way for this to cause security issues I'll probably change my mind quickly, but I can't based on a quick analysis
Messages about settings that change apart from timer related stuff shouldn't disappear. I however do think they should be messages instead of persistent features in the ui, because then you can also just get rid of them. I'm thinking of cases where a few people change the name a bunch and it gets annoying to scroll past.
This means that there was activity in the group at the time. It's odd for it not to expire.
If it doesn't expire, does clearing a conversation history get rid of it?
Ohh i understand now. if there is an expiration time set, they should disappear too. sorry, I misunderstood your question
it is metadata abt the group but disappearing messages is a feature of the whole context, if messages are disappearing then metadata shld too. Although it is a little weird if the changes persist.
Metadata changes expire. Current state of the metadata persists.
Concretely, if Alice changes the title of Foo to Bar, the title will stay Bar, but the record that she did so will expire.
There are several reasons for this:
- Any interaction with the metadata is a record of interaction with the group, which Alice may want to deny (e.g. if Alice wants to deny knowledge of messages that were sent).
- It's going to be really annoying to implement expiring messages at all without also implementing it for metadata updates.
Unless there's a really compelling argument (other than a vague "that's weird"), I'm going to stand by histories being deleted by default.