'delete link' feature' #32

New Issue

cmccabe · 2019-11-30T11:25:42Z

cmccabe commented

2019-11-30 11:25:42 +00:00

One of the great things about a decentralized system is that users own their data and can delete it at any time. Rather than making users futz with their linkulator.data files, potentially corrupting other data, lets give them a [d] option to delete a post or response. If the user chooses to [d]elete a link that has replies, linkulator should warn them that both the link and all replies will no longer be visible to anyone.

Assuming all date stamps in a single user linkulator.data file are unique, we do it like this for links (not replies):

copy ~/.linkulator/linkulator.data to a linkulator.data.bkp file
delete all data from linkulator.data, leaving a blank file
read linkulator.data into a list, one line per item
loop through the list and write back to linkulator.data when timestamp != timestamp2
-- or do a regex to match lines that do not ^start with timestamp and write them back to the file
if no timestamps were matched, then warn the user, you cannot delete content from other users. and remove linkulator.data and rename linkulator.data.bkp to linkulator.data
otherwise, if a match was found, print "deletion successful"
delete the linkulator.data.bkp file

Maybe deleting replies should also be a feature, but that would require a much bigger refactoring because there is currently no view of a reply by itself when a user could choose to delete it. Nor do we display a reply ID that a user could reference when deleting.

One of the great things about a decentralized system is that users own their data and can delete it at any time. Rather than making users futz with their linkulator.data files, potentially corrupting other data, lets give them a [d] option to delete a post or response. If the user chooses to [d]elete a link that has replies, linkulator should warn them that both the link and all replies will no longer be visible to anyone. Assuming all date stamps in a single user linkulator.data file are unique, we do it like this for links (not replies): - copy ~/.linkulator/linkulator.data to a linkulator.data.bkp file - delete all data from linkulator.data, leaving a blank file - read linkulator.data into a list, one line per item - loop through the list and write back to linkulator.data when timestamp != timestamp2 -- or do a regex to match lines that do not ^start with timestamp and write them back to the file - if no timestamps were matched, then warn the user, you cannot delete content from other users. and remove linkulator.data and rename linkulator.data.bkp to linkulator.data - otherwise, if a match was found, print "deletion successful" - delete the linkulator.data.bkp file Maybe deleting replies should also be a feature, but that would require a much bigger refactoring because there is currently no view of a reply by itself when a user could choose to delete it. Nor do we display a reply ID that a user could reference when deleting.

cmccabe changed title from ~~'delete link/reply' feature'~~ to 'delete link' feature'

2019-11-30 12:09:37 +00:00

sloum commented

2019-11-30 21:47:35 +00:00

I'm unclear re: what happens to replies in the event of post deletion. If I have a post and you have replied and I delete my post, what happens to your reply? I am strongly of the opinion that it should not be deleted. If it is not deleted then a user can still reference it, it is just an orphan and will not be loaded by linkulator itself. This does potentially create overhead, but it gives true and unconditional ownership of data to not have another user have the power to delete your content (only remove theirs, which yours depends on).

That may be what is proposed, I just wanted to check in and see if I was understanding correctly.

I'm unclear re: what happens to replies in the event of post deletion. If I have a post and you have replied and I delete my post, what happens to your reply? I am strongly of the opinion that it should not be deleted. If it is not deleted then a user can still reference it, it is just an orphan and will not be loaded by linkulator itself. This does potentially create overhead, but it gives true and unconditional ownership of data to not have another user have the power to delete your content (only remove theirs, which yours depends on). That may be what is proposed, I just wanted to check in and see if I was understanding correctly.

cmccabe commented

2019-11-30 22:21:08 +00:00

You’re right — replies are not deleted (they can’t be b/c linkulator won’t have permission) and will simply become orphans that are not displayed.

An enhancement will be for linkulator to notify the user whenever they have orphans in their data file and ask if they want the orphans deleted. I think this is described in another Issue.

[EDIT:] But prompting users to delete orphans has a downside. Either it annoys users when it prompts them each time and they decline, or we have to additionally keep track of every decline they've made. Ideally, orphan management is something linkulator should handle, but these don't seem like elegant ways to do it. Do you have any other ideas?

You’re right — replies are not deleted (they can’t be b/c linkulator won’t have permission) and will simply become orphans that are not displayed. An enhancement will be for linkulator to notify the user whenever they have orphans in their data file and ask if they want the orphans deleted. I think this is described in another Issue. [EDIT:] But prompting users to delete orphans has a downside. Either it annoys users when it prompts them each time and they decline, or we have to additionally keep track of every decline they've made. Ideally, orphan management is something linkulator should handle, but these don't seem like elegant ways to do it. Do you have any other ideas?

sloum commented

2019-12-01 03:47:11 +00:00

Each orphan would have a unique ID. A list can be kept in the data file (maybe as a csv?) of all orphans that have been kept. Then when doing a sweep for deletion (in pseudo-code):

if orphan not in keeplist:
   delete_orphan(orphan)

Something like that could work. It is more data to keep and manage. Not sure if it is worth it or not, but it is doable for sure.

Each orphan would have a unique ID. A list can be kept in the data file (maybe as a csv?) of all orphans that have been kept. Then when doing a sweep for deletion (in pseudo-code): ```python if orphan not in keeplist: delete_orphan(orphan) ``` Something like that could work. It is more data to keep and manage. Not sure if it is worth it or not, but it is doable for sure.

asdf commented

2019-12-01 08:28:48 +00:00

I suggest we should not address orphaned replies as part of this issue. It is my opinion that it does not need addressing unless there is a good reason, like a measurable performance issue.

As for the original proposal, I agree with the suggestion.

One option could be to present a "modify" action instead of delete, with an interface similar to what you see when creating a link, but prefilled. That process would allow deletion.

The interface for replies could include an index as suggested, with a command like mn, where n is an index.

Regarding how the file data is handled, a suggestion here has similar redundancy without reading in to a list first.

I suggest we should not address orphaned replies as part of this issue. It is my opinion that it does not need addressing unless there is a good reason, like a measurable performance issue. As for the original proposal, I agree with the suggestion. One option could be to present a "modify" action instead of delete, with an interface similar to what you see when creating a link, but prefilled. That process would allow deletion. The interface for replies could include an index as suggested, with a command like mn, where n is an index. Regarding how the file data is handled, a suggestion [here](https://stackoverflow.com/a/26912445) has similar redundancy without reading in to a list first.

cmccabe commented

2019-12-01 12:59:47 +00:00

I like your modify suggestion, asdf. The choice menu could say mo[d]ify or delete (where the [d] is underlined, not in brackets).

And that stackoverflow solution is good, and it is a simple improvement on bulleted sequence above.

I am fine with not addressing orphans now because, you're right, it certainly won't be an issue in the near term.

I like your modify suggestion, asdf. The choice menu could say mo[d]ify or delete (where the [d] is underlined, not in brackets). And that stackoverflow solution is good, and it is a simple improvement on bulleted sequence above. I am fine with not addressing orphans now because, you're right, it certainly won't be an issue in the near term.

cmccabe added the

future release

label 2019-12-02 03:27:10 +00:00

sloum added the

enhancement

label 2020-01-16 19:44:20 +00:00

Sign in to join this conversation.