You are viewing a single comment's thread from:

RE: Steem 0.17 Change Proposal Introduction

in #steem8 years ago

We propose removing the restriction on editing of past posts. It is a user-interface responsibility to show revision history and enable restoration of unintentional changes made by compromised accounts.

This comes with the risk of vandalizing an account's entire history if the low-security posting authority or key is compromised. A popular service with posting key access getting compromised could do a fair amount of damage. It's true that currently the risk exists, but it only goes back for 30 days. Thinking long term, it's entirely likely that a service compromise could end up with vandalizing the entire posting history of many accounts going back years.

For this reason, I'd like to suggest allowing edits going back to the beginning of an account's history BUT any edit made before 30 days would have to be made after an account "switch" is thrown with the active key. Such a switch could allow edits going back past 30 days (with posting auth), but could then be turned off at any time. Having an automatic expiration of say 24 hours on the switch may also be prudent, because many might leave it on.

Sort:  

Seems like a reasonable idea. Alternatively, a UI can allow a user to restore all of their old posts&comments.

I tend to disagree. Technically this will add much complexity and then likely harm system scalability. As mentioned in OP, make it as simple as possible. When active key is required for posting-related stuff, risk of being compromised will increase.

I think reverting recent edits can be done just as well with the posting key. The use case here is a compromised account that is then recovered by the owner (or possibly other use cases such as an author who just messed up editing the post and wants to "Undo"). After recovering the hacked account the posting key would have been changed, and then the reverts can be done using the new posting key.

The active key would be for a switch only. Not for making the edits themselves. On the web, the switch can be on a more secure page where there isn't any user-modifiable content.

It would probably be simpler to just be required to use your active key to edit posts that have passed their payout.

It would be simpler but the idea of a switch comes from the idea of segregating the active key from any place where user-editable content is located.

I'd like to echo and second this request, if I understand it rightly...

One of the highest perceived values to me personally of posting on Steemit is the promise / hope of blockchain immutability. I view the value of at least some of what I write to be durable and long-term, and I would like to think of Steemit as a place where I will be able to maintain a "legacy of thought" for anyone interested to continue to come and read into the future.

As I was reading this 0.17 change proposal, I had thought to suggest a "lockdown" switch allowing any author to permanently lock any particular post. Reading @pfunk's proposal here, I like it much better - assuming the security of my keys - because it behaves a lot like the current system (i.e. "automatic lock-down" after 30) while still allowing for intentional, key-access editing of earlier posts.

One of my uses for this "long-term" editability of a post is maintaining (on my own, using the current UI) of a Table of Contents that resides on the blockchain itself. My current workaround/hack has been to simply re-issue the TOC at 30 day intervals; with editability, I will be able to simply update the existing TOC.

To be clear the blockchain immutability is still there regardless of edits. When posts are edited, each old version remains on the blockchain. It is up to the UI to decide what if anything to show about that history, for example an option to revert recent edits.

Thank you, @smooth, for clarifying that for me. I suspected as much.
So, checking my understanding:

  • Everything ever "Posted" goes on the blockchain.
  • Every subsequent edit goes on the blockchain.
  • The entire history of a post is accessible to an appropriately crafted UI.
  • The "final presented state" of a post depends on the UI interpreting the blockchain history.

Does that sound about right? Thanks for helping me understand. ;)