Perpetual Edits? \ stacker news ~meta

2138 sats \ 24 comments \ @siggy47 3 Apr meta

I'm wondering if there is anything in the works regarding perpetual edits, as first mentioned, I believe, in this post from @elvismercury: #306665

I know that @ek, @DarthCoin and I have also talked about it over the past few months. It would really help out with territory "directory" or "index" type posts.

view all related items

263 sats \ 11 replies \ @k00b 3 Apr

We've talked about it a lot and want to do it. Somehow we don't have a github issue yet. I'll make one today.

100 sats \ 9 replies \ @WeAreAllSatoshi 3 Apr

I imagine the technical side is very straight forward and simple (like how bio posts are infinitely editable) what’s more vague is the requirements of “when should we allow this?”

107 sats \ 8 replies \ @k00b 3 Apr freebie

It's the inverse!

We always want to allow editing but in a way that's technically nontrivial (and I'd argue still straightforward to the right person).

Technically, we want items to be immutable. Each edit would create a clone of the old, apply its modifications to the clone, and the old version would be kept along with the new so that there's an edit history.

It'd work roughly like the following:

give all items a "cloneBornAt" and "cloneDiedAt" timestamp
- a new, unedited item would have "cloneBornAt" = null, and "cloneDiedAt" = null
when an item is edited
- clone it
- give the old version "cloneDiedAt" = now()
- give the new version "cloneBornAt" = now() and "cloneDiedAt" = null
- make the requested edits to the clone

The items we'd display would have "cloneDiedAt" = null, because only the most recent version would have "cloneDiedAt" = null, but the full edit history could be browsed.

Alternatively, we could create a "diff" between subsequent versions and store that for creating the edit history, but immutability is more straightforward imo.

100 sats \ 5 replies \ @WeAreAllSatoshi 3 Apr

Also, @ek is gonna blow up the DB with his edits ;)

0 sats \ 3 replies \ @k00b 3 Apr

Yeah this could be difficult to scale. Depending on how it's implemented it might also require a compound primary key on items because their id alone would no longer identify them.

I haven't looked into the diff approach much, but that'd be minimally invasive by comparison. I just don't have experience with it.

21 sats \ 2 replies \ @k00b 3 Apr freebie

Yet another approach I think that might be the goldilocks (no need for a compound primary key on "Item") is the history table pattern¹:

create an "OldItem" table using inheritance with a foreign key reference to "Item".id
on edits, copy the current "Item" to "OldItem" (taking care with primary keys and timestamps) and then edit the "Item" as usual

https://www.reddit.com/r/PostgreSQL/comments/kt1agc/what_is_the_best_way_of_implementing/ ↩

0 sats \ 1 reply \ @nym 3 Apr

What do you think about allowing reposting of old good posts, but at a considerable markup to make the repost?

6 sats \ 0 replies \ @k00b 3 Apr

I'm always interested in increasing evergreenness of old content, but I'm not sure how to do it yet.

reply on another page

0 sats \ 0 replies \ @ek 3 Apr

We could merge multiple edits in the same time window into a single edit. I think I've seen that on Github but it doesn't always seem to work that way.

or we could add a special case to limit my edits haha

maybe that is premature optimization?

100 sats \ 1 reply \ @WeAreAllSatoshi 3 Apr

Neat! I didn't realize the goal was to preserve edit history, but that makes sense!

How are deletes handled in this case? All clones are overwritten with deleted by author?

0 sats \ 0 replies \ @k00b 3 Apr

Ah good question! I hadn't considered it.

Yes, I think overwriting all clones is probably the least invasive thing.

0 sats \ 0 replies \ @siggy47 OP 3 Apr

Great!

183 sats \ 1 reply \ @StillStackinAfterAllTheseYears 3 Apr

Feature I'd love to see added with it: Subscribing to the post includes subscribing to edits as well as comments.

42 sats \ 0 replies \ @elvismercury 3 Apr

Yeah, having the "edit history" be a SN object would be interesting.

85 sats \ 1 reply \ @0xbitcoiner 3 Apr

You can always copy the post you want to edit and post a new one. To copy the post to edit, simply add /edit to the post's URL. For example: #492553/edit

16 sats \ 0 replies \ @riberet19 3 Apr

This is a good idea, but there would be many of the same posts at the end and when it comes to looking for the post it would be a bit tiring.

75 sats \ 0 replies \ @Malachi17 3 Apr

In a writer sub, it is damn near imperative.

75 sats \ 0 replies \ @030e0dca83 3 Apr

Long time ago I thought Signal had no edits because of cryptography, hash significantly changes if you edit input data and then they represented "edit" functionality.

I think possibility to perpetually edit messages here is possible but we need "edited lable".

75 sats \ 0 replies \ @Taft 3 Apr

This will be a good update, I think. And will probably decrease the number of posts like "deleted by author".

75 sats \ 3 replies \ @riberet19 3 Apr

You mean being able to edit it after the first 10 minutes, right? In most forums this can be done.

10 sats \ 2 replies \ @siggy47 OP 3 Apr

Yes, that's what I mean, but it's a little complicated. I think the SN edit limit is good for discussion posts.

185 sats \ 0 replies \ @freetx 3 Apr

One possibility is after 10 min timeout, defaults to "add only" edits. That is you cant edit / remove existing text, only add to it at bottom.

That has its own set of pros/cons of course.

75 sats \ 0 replies \ @riberet19 3 Apr

A fee could be proposed for certain posts that want to be edited, so only those who really have a real interest in editing it over time could be edited, maybe my idea is silly, but hey.

0 sats \ 0 replies \ @DesertDave 7 Apr

I like how it is.

Footnotes