You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
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)
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.)
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
Activity
webzwo0i commentedon Dec 30, 2021
milahu commentedon Dec 30, 2021
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)
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
compare: rewrite git history. sometimes this is necessary to remove private data
JohnMcLear commentedon Apr 17, 2026
Does https://www.npmjs.com/package/ep_timesliderdiff not solve this problem? If not, I'll re-open