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.
I believe that this is a feature which should not be considered on its technical merits alone. It's true that there is probably not much obstructing the implementation, and that it could theoretically be useful to someone for a legitimate purpose. If you look at it like that, of course it'd be a good thing, but technology does not exist in isolation of social realities, and it is easy to misuse it, accidentally or intentionally.
This particular feature has a few, niche, listed use-cases, most of which seem to be legitimate, but also a lot of ways in which it can be misused...
Create an environment that encourages harassment (the "stand by what you say" idea)
Prevent users from burying things, or otherwise leaving them in the past
Make it more difficult for users to leave a community, by forcing them to take all or none of their messages with them
Admins enable because they, somehow, like it better that way
And, the original concern, of making the platform significantly less usable for a subset of people, still stands.
I don't think any of the provided remediations for these issues are effective.
A scare screen would be in opposition to regular use for a channel. Either the scare screen is reduced to the point of ineffectiveness, or it is sufficiently annoying to obstruct general discussion. Given the issue of alarm fatigue, I don't think there can be a good middle-ground in designing a scare screen like this, but there hasn't been any user testing, so that might not be true.
An alternate design might, alongside a scare screen, have a little notice in the bottom right, like the slowmode indicator. If you do want to do user testing, try adding that...!
Edit slowmode either doesn't do anything to stop edit trolling, if you can edit once after sending a message, or, if you can't, obstructs significant real editing usage, like typo corrections and adding context. It also doesn't do anything to solve edit trolling if the slowmode duration is too short, since you can just wait, say, one minute, then edit the message like normal.
Edit windows are probably the best idea here, but there are still valid reasons to edit a message, say, five minutes after it's been sent. It might be a low-traffic channel with long messages, like many of the topic channels in Fluxer Labs, or it might be a living message, pinned or linked to, which would benefit from being updated long after its initial sending.
Making it exclusive to self-hosted instances has been discussed at length, and I won't bother to repeat it here. Everything that Fluxer (software) can do becomes a part of Fluxer (platform), as soon as federation is involved, so I don't think this is sufficient to stop misuse, and Fluxer Platform AB is at least partially responsible for what features they allow on Fluxer (platform). If Fluxer.com were to choose not to enable this feature, that means there is a significant reason behind the choice, as the default choice is lower-friction, and gives broader access to more features of Fluxer (software). Nobody has posed objections which are not related to safety or data privacy, so it is a rather safe to assume that those are the reasons.
Sure, you can choose to leave communities and instances that enable this, but that means you're being excluded from them. It would be best to not hand out access to levers that exclude people. Some people would pull it for fun, others would pull it out of malice, but you know that someone is definitely going to pull it.
I also do not accept that the ability to disable message deletion is OK, purely because you can choose to leave a community and delete all of your messages. That adds a lot of friction to what should be a simple action of deleting a single message, which ultimately requires a choice by the user: assuming they can even rejoin the community, do they value getting rid of that one message more than all of the messages they've sent there? You might be surprised by how little attachment users have to their messages, and I, personally, would probably choose to get rid of everything. If anyone chooses to do that, the purpose of the permission has been defeated, and you lost context in previous conversations, and records of real participation in your community.
I ultimately believe that these features go against one of Fluxer's goals, to enable easier data privacy for all users. It should be as easy as possible to control exactly what data you have on Fluxer, who can see that data, and what the data they see is. The ability to disable editing or deletion in a channel would, completely unnecessarily, make it more difficult, in service of use-cases that are either already covered by existing solutions, or already obstructed by non-optional features of Fluxer. There is also the potential (the only thing there can be, since the feature doesn't exist yet) for harm, and a significant impact to usability.
I have raised the alternative solution, of a Fluxer fork, "Business Fluxer", which adds the feature, and removes support for federation with standard Fluxer, in a way that is not trivially reversible. Ideally, it would be maintained by businesses that require it, or even officially, by Fluxer Platform AB. This fork would already be necessary to use Fluxer in a business context, as Fluxer is making a point of having data privacy features, like the ability to delete your account and all messages that it has ever sent, and these features are always enabled, for all users, on all instances. This would remain true, and unaffected by the presence or absence of editing and deletion permissions, unless Fluxer goes back on this, and makes those features optional, which I believe would significantly ease abuse on a federated network.
I don't think the good outweighs the bad here, and being reductive about the bad won't help. You do not have my support.
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
- Create an environment that encourages harassment (the "stand by what you say" idea)
- Prevent users from burying things, or otherwise leaving them in the past
- Make it more difficult for users to leave a community, by forcing them to take all or none of their messages with them
- Admins enable because they, somehow, like it better that way
And, the original concern, of making the platform significantly less usable for a subset of people, still stands. I don't think any of the provided remediations for these issues are effective.- A scare screen would be in opposition to regular use for a channel. Either the scare screen is reduced to the point of ineffectiveness, or it is sufficiently annoying to obstruct general discussion. Given the issue of alarm fatigue, I don't think there can be a good middle-ground in designing a scare screen like this, but there hasn't been any user testing, so that might not be true.
- An alternate design might, alongside a scare screen, have a little notice in the bottom right, like the slowmode indicator. If you do want to do user testing, try adding that...!
- Edit slowmode either doesn't do anything to stop edit trolling, if you can edit once after sending a message, or, if you can't, obstructs significant real editing usage, like typo corrections and adding context. It also doesn't do anything to solve edit trolling if the slowmode duration is too short, since you can just wait, say, one minute, then edit the message like normal.
- Edit windows are probably the best idea here, but there are still valid reasons to edit a message, say, five minutes after it's been sent. It might be a low-traffic channel with long messages, like many of the topic channels in Fluxer Labs, or it might be a living message, pinned or linked to, which would benefit from being updated long after its initial sending.
- Making it exclusive to self-hosted instances has been discussed at length, and I won't bother to repeat it here. Everything that Fluxer (software) can do becomes a part of Fluxer (platform), as soon as federation is involved, so I don't think this is sufficient to stop misuse, and Fluxer Platform AB is at least partially responsible for what features they allow on Fluxer (platform). If Fluxer.com were to choose not to enable this feature, that means there is a significant reason behind the choice, as the default choice is lower-friction, and gives broader access to more features of Fluxer (software). Nobody has posed objections which are not related to safety or data privacy, so it is a rather safe to assume that those are the reasons.
- Sure, you can choose to leave communities and instances that enable this, but that means you're being excluded from them. It would be best to not hand out access to levers that exclude people. Some people would pull it for fun, others would pull it out of malice, but you know that someone is definitely going to pull it.
I also do not accept that the ability to disable message deletion is OK, purely because you can choose to leave a community and delete all of your messages. That adds a lot of friction to what should be a simple action of deleting a single message, which ultimately requires a choice by the user: assuming they can even rejoin the community, do they value getting rid of that one message more than all of the messages they've sent there? You might be surprised by how little attachment users have to their messages, and I, personally, would probably choose to get rid of everything. If anyone chooses to do that, the purpose of the permission has been defeated, and you lost context in previous conversations, and records of real participation in your community. I ultimately believe that these features go against one of Fluxer's goals, to enable easier data privacy for all users. It should be as easy as possible to control exactly what data you have on Fluxer, who can see that data, and what the data they see is. The ability to disable editing or deletion in a channel would, completely unnecessarily, make it more difficult, in service of use-cases that are either already covered by existing solutions, or already obstructed by non-optional features of Fluxer. There is also the potential (the only thing there can be, since the feature doesn't exist yet) for harm, and a significant impact to usability. I have raised the alternative solution, of a Fluxer fork, "Business Fluxer", which adds the feature, and removes support for federation with standard Fluxer, in a way that is not trivially reversible. Ideally, it would be maintained by businesses that require it, or even officially, by Fluxer Platform AB. This fork would already be necessary to use Fluxer in a business context, as Fluxer is making a point of having data privacy features, like the ability to delete your account and all messages that it has ever sent, and these features are always enabled, for all users, on all instances. This would remain true, and unaffected by the presence or absence of editing and deletion permissions, unless Fluxer goes back on this, and makes those features optional, which I believe would significantly ease abuse on a federated network. I don't think the good outweighs the bad here, and being reductive about the bad won't help. You do not have my support.