Lemmy

How much extra storage and bandwidth would it use? It's just text. It's clear that you don't like the idea, but I don't find your reasons convincing.

Well, I was of the other opinion, but you have decisively convinced me, thank you.

Thoughts on the cons of making all upvotes visible to all users? I've always felt that would be a net benefit, but now I'm not so sure. Any idea?

What you think adds a feature actually takes away a feature (being able to edit posts without the edit being visible). That isn’t a bug, it’s a feature.

Do note that a feature's mere existence doesn't necessitate that it must be a good feature.

Increased hosting costs to operate it (storage)

I don't believe that this is much of an issue, as text is extremely cheap to store. It would, of course, be false to state that it doesn't increase the cost at all, but I would argue that the increase in cost is most likely small enough to be of little concern. Let's make a very basic, and not overly precise example: Say, on average, there is 100 words in each Lemmy post's body. And say, on average, that a user will edit 10 words. Now, say that the algorithm that generates the changes, only stores the changes relative to the previous content, so we can then simplify this to say that it only stores the text plus, say, maybe 1 extra words worth of data for location, and linking information. So that means that each post will only add on maybe 11 words on average which would equate to a 1.1% increase in text storage requirements. Given that all of Wikipedia's Engish article text is around 20GB, a 1.1% increase in that is only about 220MB -- one should be able to see that the equivelant for Lemmy wouldn't be that terrible.

Increased API calls and sizes (bandwidth)

I'm not sure that I am qualified enough to make a comment on this, as I am not at all an expert in how Lemmy's (or ActivityPub's) Networking works under the hood, but how would this differ from how it already works? You can already make an edit, so the number of API requests should stay somewhat the same. The only thing I can think of is that when someone opens the edit history, they would need to make a few API calls to retrieve it all, unless all that could be retrieved in one call, then it should be the same as displaying the date of the last edit which is a feature that already exists with the only difference being the payload size in that case.

99.999% of feature use is just typo correction

Sure, but I don't see this as a counterargument. The whole point of it is to be able to verify that it is indeed a typo correction.

99% of users won’t use the feature

True, this could be seen as an investment that may not be worth it as it would really only cater to those who are, perhaps, on the upper end of paranoia, or overly persnickety.

It invites users to review people’s edit history and nitpick/call out things that the poster edited out for a reason…

This is a fair point. I hadn't considered this. I do think that it wouldn't be super common, it is indeed a possible issue.

Which in turn breaks down and chills conversation as users have to be overly careful that their comment or post is 100% accurate to avoid getting nitpicked, that they fully agree with what they’re saying as they can’t take it back or edit their stance/opinion in the future, that they don’t reveal anything sensitive by mistake

I mean, it's kind of already like this, is it not? What you say is certainly under scrutiny by the court of public opinion. Unless you mean that one cannot take something back because it would be ingrained in the edit history, but, to that, I would say that one can still delete their post.

It invites abuse from mods by reverting edits and dictating which “version of truth” of a post is the one that everyone sees rather than the user being in control.

Hm, I think this is a completely separate issue. A mod, or admin should not be able to do such things. This actually brings up a separate idea that I had where, ideally, a post would be signed by the user who wrote it so that one could be certain that it was the user who indeed wrote the post, and that it was not modified by an admin, or some other external entity. This censorship is an existing problem with no solution.

Extra UI cutter is needed to handle the feature

The button that would contain the history already exists in the form of the edit pencil that posts have. Unless you mean the diff itself, but that would only be visible if one toggles it.

If a user posts credentials, they have to delete the entire post or comment and even then, the backend server very well could still have that log saved in a backup (legal ramifications)

Yeah deleting would be the only option -- personally, I don't see this as a huge issue, but that's just me. As for the logs, they could already exist for a deleted post anyways. When you post something online, there really is 0 guarantee that you can ever remove it. Generally, one must accept that whatever they put online is out there, in some capacity, forever.

Users could abuse the feature to e.g. share links to abuse material and hide it in the log requiring moderators to have to review all messages and all edit histories, greatly increasing their work load, especially if users constantly edit their posts to make moderators jobs harder to sift through all the edits to reveal what they did.

Good point. I hadn't considered this issue. I would argue that it's the most important point of your list. I'm not sure that there is anything that could really be done about it. It would essentially have to rely on someone reporting it after having gone through the edit history, or a mod just happening to have gone through the history themself.

will have a direct, chilling impact on all other users.

Aha, you don't need to use such melodramatic language to try to magnify your opinion -- your counterarguments should be enough.

if you need audit logs, you do it behind the scenes not in the UI

Do note that this is supposed to be for the benefit of the user, and not the admins. A user cannot access logs.

Visible changelogs on information chat / social systems make people talk less, not more.

I would like to know your source for such a statement.

And given how Lemmy is still in its infancy and hasn’t reached a critical mass, adding a feature like OP proposed could make Lemmy a far less inviting place to socialise.

This is a purely subjective statement, I would argue.

increased hosting costs

Should be minimal since it's text. In fact, a lot of my edits reduce posts since I use it to add an edit that I would've needed to post in multiple sub-threads.

99% of users won't use the feature

Which further proves that it's not likely to cause many hosting costs.

invites users to review people's edit history

They already do this with comment history. If you don't want people digging in to your edit history, don't make controversial edits.

People being jerks for calling out typo fixes likely will result in downvotes, thus discouraged by the community. Look at grammar police, they're frequently downvoted to the point where they're not very common (though more common than they should be).

be overly careful that their comment or post is 100% accurate

First, that remains to be seen. You yourself said 99% of people won't use the feature, and I think it'll turn out much like the grammar police, people calling out others for small mistakes will be shunned. I could even see mods making and enforcing harassment rules related to behavior like that.

Second, if it improves the quality of comments and posts, I don't see that as a bad thing. Perhaps individual communities could disable it, but it should absolutely be enabled for serious communities that cover politics and news.

abuse by mods by reverting edits

Then don't give them that power. Just allow them to lock posts and leave a note or a flag to warn users of abuse by the commenter.

Extra UI clutter

Not necessarily. You can pick a client that doesn't implement the feature. Or you can have it be an optional feature, or hide it by default in an expandable menu. It doesn't cause clutter in Wikipedia, so it's not inherently a poor UX choice.

We can bike shed the UX once we agree on the functional requirements, that's how the design process is intended to work.

If a user posts credentials

This is a federated platform, you should assume everything you post is there for good on some instance.

Users could abuse the feature

Sure, but they can do it anyway in the clear by sending DMs, changing text of links to look innocent, etc.

I think there should be an option to show edits always, which would catch this issue. So basically you'd be looking at the equivalent of inline git diff (with strikeouts or whatever to show deleted content). That's how I'd prefer to navigate Lemmy, and I'm guessing enough others would as well to catch any attempted abuse.

less inviting place to socialise

Then I guess you and I see the platform very differently. I see it as a place to discuss news and politics, not a place to "socialize." It's a link aggregator, so I expect the bulk of the discussion to be about the content of links.

That said, there are plenty of casual communities that work more like forums that want to foster casual discussion, not serious discussion. For those, edit history should probably be disabled. So make it an opt-in thing by community so those of us that want it can have it.

Your are absolutely right. I guess I had accidentally copied the wrong link. Thank you for letting me know! I have now updated my post.