Modern chat networks/apps allow the authors of messages to edit them delete them manually, and even delete them automatically after some amount of time after being read. These abilities are great, and we intend to support them, but libpurple allows their users to log messages locally and that creates a dilemma when it comes to these messages.
The message authors will expect these messages to behave like they do in the official app/protocol implementation, but there are libpurple users that would like to keep a history of these messages.
From the libpurple side we absolutely must implement these features in the expected fashion, but
there isnāt actually much we can do to stop a plugin from being able to save the old message. We need to tell user interfaces about deleted/edited messages and a plugin could hook into that API, look up the previous message before itās deleted/edited and then store it separately anyways.
So the question becomes how transparent we want to be about this ability to all users, not just libpurple/pidgin users and should we make it easily available to anyone. Bad actors will figure it out and use it regardless with any client. We can and will post something here or on the website documenting all of this, but in reality most users wonāt see/read any of that, but that is the least we could do.
So the question becomes how easily should we make it to save these deleted messages?
We could make this as easy as a preference, something named like āarchive original and deleted messagesā which would default to off. This would make it very obvious to anyone going through the preferences and would explicitly state that this is possible while still doing the expected thing by default
The other option is to implement this via a plugin. That plugin could be in our source tree or external. Conceptually thereās not much difference between an in tree plugin and a preference, except that the plugin might be a bit harder to find so instead lets focus on an external plugin.
An external plugin would work just like an in tree plugin but it would be harder for people to discover. Thatās probably a good thing in this specific case, but it would also be harder for people that would be victimized by the feature too.
Iāve been thinking about this all day and am actually kind of leaning towards the preference option defaulting to off, but would really like to hear the opinions of others. As such, please feel free to vote on which you think is the best option and provide any comments you may have!
- Build it in and control via a preference
- Create a first party plugin in tree
- Create a second party plugin out of tree
- Do nothing (let others add the feature)