Separate out "edit own messages" and "delete own messages" permission in community permission settings

(#3454) Feature Under consideration community moderation

Thread

Comment by @fluxerhost
RexSystem 1 vote originally by @fluxerhost on GitHub OP 1 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.
Comment by @Shardion
RexSystem 1 vote originally by @Shardion on GitHub
We are discussing the potential harm of this feature right now. These features probably do not impact federation on a technical level, but they do impact the resulting federated Fluxer platform, since people can access communities within an instance through federation, being subject to its own configuration, as opposed to that of their home instance. I feel that it is against the goals of Fluxer to allow instances which disable data privacy features to exist in the federated network. It's important to note that, in federation, all features will be implemented eventually. It can't really be helped, so federation must be designed in a way to minimize the impact of instances which operate in an undesired or unintended way, and, to minimize the chances that an instance operator will attempt to do that. This is why I feel that having it as a toggle which Fluxer.com disables is not sufficient for this feature to exist. Not only would it require extra development work on Fluxer Platform AB's side, for a feature that they don't intend to use, and doesn't further their goals, but it also significantly lowers the friction involved to have this feature, from "fork Fluxer and add it yourself", to "go into the container and delete the line preventing federation without data privacy".