FIP 2: Editing support

[denisnazarov]

Abstract

Blockchains are immutable, append-only data structures, making modification or deletion of confirmed transactions is not possible.

Since FEEDweave allows posting of arbitrary markdown, it is common that users will make mistakes in their posts and will want to either edit them or delete them.

Editing support can be implemented using diff techniques commonly version control systems such as Git, which also utilize immutable data structures.

Specification

Here is an example of a diff using the unix diff tool. Let's assume we have two versions of a post. file1 is the first version and file2 is the edited version.

$ cat file1.txt
I need to buy apples.
I need to run the laundry.
I need to wash the dog.
I need to get the car detailed.

$ cat file2.txt
I need to buy apples.
I need to do the laundry.
I need to wash the car.
I need to get the dog detailed.

Here is what a diff would look like.

$ diff -u file1.txt file2.txt
--- file1.txt   2020-02-11 11:43:40.000000000 -0500
+++ file2.txt   2020-02-11 11:43:50.000000000 -0500
@@ -1,4 +1,4 @@
 I need to buy apples.
-I need to run the laundry.
-I need to wash the dog.
-I need to get the car detailed.
+I need to do the laundry.
+I need to wash the car.

Although the diff output is bigger than the new version for this contrived example, it will generally be more efficient to store the diff for bigger files.

Now, to implement editing as a reusable Arweave data app, we can use App-Name: text-revision. A transaction payload would look like this:

{
  "data": DIFF_DATA,
  "tags": {
    "App-Name": "text-revision",
    "Parent-Transaction": TX_HASH
  }
}

Parent-Transaction can point to a top-level FEEDweave post, or be chained with a previous diff. It is up to the client or gateway to apply the diffs in sequence to render the most up-to-date revision of a post.

Clients can also display a revision history in the UI.

To do

• [ ] evaluate the most efficient format for storing a diff

[LeGaryGary]

I might use this for my commit system in GitWeave once it is implemented as its the same functionality.

Also it would be cool there was a JS library per App-Name that people could contribute to to stop the same client code being written multiple times. This could be how we can create a healthy ecosystem of data re-usability.