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

Many features can decrease usability, as usability is relative to the function of a space, which is determined by community admins. I think this should be a feature which Fluxer offers, even if it disables it instance-wide on the fluxer.com instance. Self-hosted instances should be able to use granular ACLs/permissions without needing to fork the code.

If Fluxer.com has to disable a feature, instance-wide, due to safety and privacy concerns, that isn't a very good argument in favor of giving the feature to other instances. Personally, I do not believe that platform features should be removable, purely because they technically can be, which is how I interpret your argument here. Do you have any more example use-cases for this feature, which might justify its inclusion?

There are no safety or privacy concerns with the feature. Fluxer.com has not stated so, and I don't see any. Granular ACLs are reason enough to have granular ACLs. It is widely accepted in the industry that granular ACLs are a good idea.

Mistakes are fine and people should understand that. An edit or delete timer would solve the autocorrect issue. I still think that community owners/administrators should be able to have granular feature/ACL control in their communities, without artificial technical barriers.

An "artificial technical barrier" is often left in, or placed intentionally, to prevent people from doing something that would be to someone's immediate or eventual detriment, like a Chesterton's fence. I feel that the ability to edit and delete messages would have already been a permission on Discord, like sending or attaching files, had it not been judged a bad idea, and intentionally excluded, making this an example of an intentionally-placed barrier, not a technical limitation.

I don't think Discord is a good judge of features

"edit trolling" was just one example use case -- expanding ACL granularity is fundamentally good on a technical level, regardless of use case. An "edit slow mode" would work for that one use case, but that would address a symptom, not the root, of the issue (undifferentiated ACLs)

Federation is a good consideration, but out of scope. This feature would not impact federation.

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?

I don't think forking is the right suggestion for harmless features, especially expanding existing ACLs into granular ACLs. I don't think a corporate entity would federate with internet-discoverable instances anyway (probably only with other corporate instances), and expanded ACLs do not impact federation either way for non-corporate use caes. In the case of a corporate use case, "leave and delete my messages" from a community would probably have to be toggle-able at the instance level (new gh discussion), and even deleting an account would have to be toggle-able at the instance level as well (new gh discussion). Those, however, are separate feature adjustment discussions, i think -- this github discussion is focused on a portion of the features needed to support such a use case: expanding the ACL granularity for message actions (to split out edit and delete permissions).

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".

I don't think this feature has any harm. Expanded ACLs are always better than opaque ACLs. This feature does not impact privacy either. Channel visibility is still controlled by admins and roles, via ACLs. Perhaps only instances running the same code will be able to federate with each other - which is why it is important that this feature is treated seriously and part of the official codebase, even if unused on the main fluxer.com instance. I think it is sufficient for this feature to exist. The use case is a real one.

There is nothing that can enforce an instance to only be able to federate with other instances running the same code, and it doesn't happen automatically, even when incompatible changes are introduced. This is actually why I suggested a fork! If such a fork existed, say, "Business Fluxer", and was made intentionally incompatible, maybe by ripping out the federation code entirely, then the legal use-case could have its own Fluxer, without the data privacy features for compliance reasons, and personal users on the federated network get to keep their data privacy in the safest way possible.

I think suggesting a fork is not the right move for anyone involved and that a fork for expanded ACLs a waste of effort. I think this is a valid feature to exist in the main Fluxer codebase. Again, this feature does not impact privacy or safety negatively.

To clarify about the potential privacy and "harm" concerns: The concerns listed about "harm" are both theoretical and potential, not actual or clearly listed. Any administrator can use any feature in a harmful way - such is the way of any technology. How a person uses any technology is not in the realm of consideration of a technical feature such as granular ACLs. The concerns listed about privacy are also not relevant to this feature - not only would the feature be toggle-able at the instance level, and even further, would be toggle-able at the community, and ultimately at the ACL level, as proposed here, per role or channel (like other permissions), but also, the "right to be forgotten" is covered by two features already: the community-leave-and-delete-all-messages feature, which would be unaltered by this feature, or the delete-my-account-and-all-data feature, which would also be unaltered by this specific feature request, as proposed. I think vkyfox explained about safety and privacy concerns well as well: https://github.com/orgs/fluxerapp/discussions/3200#discussioncomment-18748231

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.