Preserving steps which have failed during rebasing

I am trying to use ProseMirror rebasing capabilities for situations where two clients might be out of sync for a longer time (offline mode which tries to resync after reconnecting). I am looking at rebaseSteps and it seems that steps which are out-of-date because they cannot be mapped anymore (if I understand correctly, because the part of the document got deleted) or applied anymore (would produce invalid structure) are simply ignored. In this way, after rebasing, user in fact looses data stored in those steps.

I am looking into ways to preserve this data somehow. So one question I have is what would be a good way to combine multiple such failed steps together into a maybe separate document which I could display after rebasing saying that this is the content which got removed, and ask the user to maybe re-add it to a correct place.

The rebasing approach is only reasonable for interactive use, when the user is looking at the context they are editing. For a situation like the one you describe, they are probably not a good approach. Some kind of tree-diff algorithm, which detects conflicts that you can then submit to your users for manual resolution, is probably the way to go there. But I’m not aware of anyone having implemented such a thing, so far.

Yes, I am familiar with the alternative using the tree-diff algorithm. I am experimenting with different (new?) collaboration techniques and I am trying to see if I can design a workflow more alongside “don’t ask for permission, ask for forgiveness” approach. Where in the case of conflicts I would merge/rebase automatically, but show to the user what changed and what has to be reviewed and confirmed as valid. So determining what has changed and not been deleted seems easy. What I am struggling is how to extract in a meaningful way what has been deleted. So then user would get a view to review merges and also section which would include all deleted content and if they want, they could just copy-paste it again into a document and continue editing.

The prosemirror-changeset package might provide some inspiration. In general, by mapping the replaced ranges from a sequence of steps backwards to the start document you can create a map of all the content that was deleted by that sequence of steps (and similarly, by mapping the inserted ranges forward, you can get a view of what was inserted).

I think I see. When rebasing does not add a failed step, then the whole transaction effectively has only the initial undo step for that step, removing the content (instead of having also the redo step). So I could look at the whole transaction and see what was removed. Now the tricky part is how to determine what was removed as part of failed rebasing steps and what as regular steps which just happen to remove some content. I will have to think a bit about this. Thanks.