Open xundeenergie opened 2 years ago
For once I'd like someone to point me out to an actual example of malicious switcharoo with post editing where someone was actually harmed from liking or commenting on a post that was later edited.
For about 15 years this has been the number 1 hypothetical I've seen used against implementing post editing anywhere it wasn't available and I've yet to see any evidence this argument is based on anything but FUD.
Besides, we do show that the post was edited and when, so there's no way someone can credibly claim that any like or comment was meant about the altered content without interviewing the author.
I don't see a huge problem storing the different versions. The history shouldn't be that much of a problem.
I've been on facebook in a group with historical images about Innsbruck. There habe been hundreds of members. It was one of many groups for historical images about different regions/cities.
One day this group changed to a Fansite for the far right party FPÖ from austria...
Ok... it was not a posting... but it was the same thing...
So far, I'm not aware of any bad event happened with editing posts in the last decade. But in general I'm not against having some sort of history/diffs or so for edited content. Most of the time it will probably rather uninteresting typos, but if someone would want to build it, why not.
I know, that it is rather uncommon to write very long postings, but the length of a posting is rather unlimited (MEDIUM_TEXT has some 16MB upper limit) so each historic version might be unpractical for storage?
Storing the post history does introduce an additional layer of complexity, but given the sheer amount of posts a Friendica node deals with on a regular basis and how rarely this feature is used in general, I don't think it would make storage unmanageable.
I don't mind storing the different versions of a post either, but the original argument for it that I criticized is really tired.
It would be one additional table (with the content data, the uri-id
and the creation date). This data would only be filled in a case of editing. I don't think that it will be a storage problem.
I noticed that edited posts are not federated with other softwares. I second the idea of history like it's done with Mastodon or at least having an edited_at
:
edited_at
Description: Timestamp of when the status was last edited.
Type: NULLABLE String (ISO 8601 Datetime)
Also, it seems /api/v1/statuses/:id/source
returns something not human readable for mentions, but it works.
For instance, @apps@toot.fedilab.app
will be written when editing @{Fedilab Apps; apps@toot.fedilab.app}
Edit:
History does not seem to be available in the same way it is for the Mastodon API.
I'd just like to add that I too would like to see this feature.
What if, storing only the diff, in case of editing?
A little like git... would save amount of storage.
Is the feature request related to a problem? Please describe.
Editing a posting or comment is a great thing. To fix typos (thanks smartphones and big fingers...) or fix others... add links or pictures. But an edited posting/comment has bomb-potential... you like a posting, that flowers are so beautiful, and then the creator changes it to "all flowers are bastards and have to be extincted"... an my like is still on this posting...
Describe the feature you'd like
Do not show only "Posting was edited $TIME ago", show a link to the past versions. And show to which version a like/dislike was set. For the first lesson i think it is enough to open a popup-window (or overlay-div) with a dropdown or radiobuttons for each historic version and show this in a textfield - including the likes. No diff... just to have a POC