I believe that the addition of an edit history would be a massive boon to the usefulness of Lemmy on the whole. A common problem with forums is the relatively low level of trust that users can have in another’s content. When one has the ability to edit their posts, and comments this invites the possibility of misleading the reader – for example, one can create a comment, then, after gaining likes, and comments, reword the comment to either destroy the usefulness of the thread on the whole, or mislead a future reader. The addition of an edit history would solve this issue.

Lemmy already tracks that a post was edited (I point your attention to the little pencil icon that you see in a posts header in the browser version of the lemmy-ui). What I am describing is the expansion of this feature. The format that I have envisioned is something very similar to what Element does. For example:

What this image is depicting is a visual of what parts of the post were changed at the time that it was edited, and a complete history of every edit made to the post – sort of like a “git diff”.

I would love to hear the feedback of all Lemmings on this idea for a feature – concerns, suggestions, praise, criticisms, or anything else!

This post is the result of the current (2023-10-03T07:37Z) status of this GitHub post. It was closed by a maintainer/dev of the Lemmy repo. I personally don’t think that the issue got enough attention, or input, so I am posting it here in an attempt to open it up to a potentially wider audience.

  • density@kbin.social
    3·
    9 months ago

    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.

    If you make a post which is 1000 chars in length, then you edit it to be only 800 chars, the 1000 chars still need to be stored. And federated and everything. That is the actual idea being presented here. It might not be a total of 1000+800=1800 chars because there are clever ways of compressing stuff, but it is still >1000 and certainly >800. And as @fartsparkles also pointed out you need to track meta data for each edit in addition to the text.

    It doesn’t cause clutter in Wikipedia, so it’s not inherently a poor UX choice.

    Interesting comparison. Wikipedia has a very robust system for tracking changes, because it is a core feature of the project. It is a collection of collaboratively edited documents. Since that’s the whole idea of the project, they have rules, software, code, humans, robots, meetings, arguments, computers, etc to manage it because it is really complicated.

    Sometimes, it is too much and they just wipe it away https://en.wikipedia.org/wiki/Wikipedia:Selective_deletion

    Threadiverse is not a collaboratively edited collection of documents so why introduce that? There is no compelling argument presented.

    Also mentioned is git, which like wikipedia is primarily a tool for collaborative editing. It also has the ability to permanently remove: https://git-scm.com/docs/git-filter-branch Not to mention using git is a very specialized skill primarily attained through formal education and employment.

    Both wikimedia and git are known as very complicated to use pieces of software which take years of practice to be good at. Both have their own subcultures. They have to be like this because they are trying to accomplish a complicated task, which is to allow large number of people to collaborate together. I think compare/contrasting these to threadiverse does a great deal to show what actually happens when you need to have changetracking like this and how difficult it is to design properly in such a way that it can be easily used by a common person without significant study.