RexSystem1 voteoriginally by @fluxerhost on GitHub OP1 reply
Example use case for this feature: running fluxer in a corporate setting, or for a law firm.
"Legal discovery" and evidence preservation for all messages must be preserved.
If an employee leaves or is fired, they don't get to take their messages with them.
If an employee is involved in a corporate investigation (e.g. harassment), the investigations team should be able to extract all messages sent by the user. Message immutability via expanded ACLs is a good first step to support such safety.
It is more technically complex, but also a good idea, to preserve all edit and delete history, however it is also a good feature and easy to implement to add message immutability/making the ACLs around messages more granular.
This use-case probably interacts badly with Fluxer's existing data privacy features, so those will have to be considered as well, when determining if Fluxer should support it or not. I would personally wish for this to be out-of-scope, since I don't want edit- and deletion-blocking to exist in the federated network, but it might be a good basis for an (incompatible!) fork?
Thread
Comment by @fluxerhost
Example use case for this feature: running fluxer in a corporate setting, or for a law firm.
"Legal discovery" and evidence preservation for all messages must be preserved. If an employee leaves or is fired, they don't get to take their messages with them. If an employee is involved in a corporate investigation (e.g. harassment), the investigations team should be able to extract all messages sent by the user. Message immutability via expanded ACLs is a good first step to support such safety. It is more technically complex, but also a good idea, to preserve all edit and delete history, however it is also a good feature and easy to implement to add message immutability/making the ACLs around messages more granular.Comment by @Shardion