"track changes" feature: show deleted text

[milahu]

"track changes" feature

• show a character-based "diff view" of the document. deletions are red, inserts are green
• allow to accept or reject changes, so the deletions are finally removed, and the inserts lose the green color

useful to

• moderate changes from untrusted sources
• improve end-user involvement by in-place editing of documents

example

context-before this-text-was-deletedthis-text-was-inserted context-after

accept this change:

context-before this-text-was-inserted context-after

note that this-text-was- is redundant, its both in deleted and inserted text.
this is desired, to visualize the human-intended change,
not the machine-interpreted change, which would produce a smaller diff

demos

• ckeditor with "track changes" feature
  • also has "accept/reject changes" feature
  • "premium plugin" = commercial
• prosemirror with "track changes" feature
  • using the "track changes" module of fiduswriter
• my from-scratch implementation of a "track changes" editor
  • buggy, incomplete

challenges

visualize deletion of style. example: mix html tags with rich text

context-before <b>content-is-same</b> context-after

plugin

Might this feature be better suited to being a plugin?

"show deleted text" should be possible with the current etherpad-lite

"accept/reject changes" ...
send accept/reject events to other users.
permissions: who can accept/reject changes? who "owns" the document?
how to resolve conflicts? -> allow users to start "hostile" forks
imitate git branches and github PRs/forks? -> nonlinear history

[webzwo0i]

Sounds like a good idea, but we need to differentiate what (if anything) is needed in core to make this work and if this can be done as plugin or if it's really that helpful that we want to make this part of core. One problem, as you said, is session attribution: What is the best method to accomplish public pads while having some kind of pad ownership/rights management? ie the "moderator" clicks "track changes" but how does Etherpad know that it's the "moderator" who wants to "merge" the changes in? Obviously we can base the decision on express_sid, but this is not very user-friendly (ie user deletes cookies, user is in incognito mode, user changes browser etc). Naturally, we can give anybody the ability to use track/merge because every revision is stored, so any revision can be restored. In combination with some kind of "fork this pad with history" functionality (which is already possible via .etherpad export) this might be helpful. However, what problem/use case should be solved? - If we export a pad with a large garbage history due to vandalism, we don't want to import the garbage into the new fork. - If we fork due to vandalism, why would it matter to have a new pad id? In cases where a pad id is publicly available and we want to move to a new pad without making the id publicly available we already can do this. - Do we want to remove old revisions because they are vandalism? (This is something that probably won't go into core) Some kind of "revert revisions x1,x2,x3,x4..." functionality is something I would definitly want to support. I can imagine this to be very useful, but maybe as part of the timeslider, ie diffing two arbitrary revisions. But suppose the head revision is at 500 and you want to compare revision 300-400. Etherpad can't find out if the changes that are done between 300 and 400 are still "present" in revision 500. We can try to use line numbers and output all changes that are made to a specific line, but this is problematic (e.g. when line index changes)

[milahu]

that escalated quickly ; )

example scenario:

lets say you and me work on a document.
i'm a maintainer, you're a contributor.
the document is hosted in a git repo,
but development happens in etherpad (or similar collaborative editor).
(i assume this way is more user-friendly than github pull-requests.)

so ... you propose changes, i review your changes (accept/reject/modify)
after some back-and-forth, we reach consensus,
i commit the new version to git, the etherpad history can be deleted.
(in other words, the million etherpad commits are squashed into one git commit.)

im using matrix as transport layer for CRDT messages, see applications beyond chat
the matrix element client can embed etherpad-lite as widget (video)

public pads

only matrix users have write access to the pad
so the contributors are only "untrusted" but authenticated (less vandalism)
access control is done by matrix -> ownership, write access

Do we want to remove old revisions because they are vandalism?

compare: rewrite git history. sometimes this is necessary to remove private data