GSoC 2026 Proposal Draft – Idea 9: Automatic conflict resolution – gherardi

GSoC GSoC Proposal Drafts
1

Links

1. Introduction

  • Background / studies: Computer Science student at the University of Milan (Italy :italy:) with a strong interest in software engineering and systems design.

  • Programming experience: Solid experience with algorithms and complex architectures through projects like wyag (version control system implementation from scratch) and shell-c (unix shell in C).

  • Experience with open source: Participant in the Joplin community through advice and contribution preparation, and have also engaged with Submitty (open-source organization), where I have an active pull request

2. Project Summary

  • What problem it solves: Currently, Joplin doesn’t handle notes conflict when the same note is edited on different devices, requiring tedious manual merging by the user.

  • What will be implemented: A deterministic conflict resolution engine that uses three-way merge and text diff algorithms to automatically combine compatible edits.

  • Expected outcome: A system that reduces manual merging while providing a dedicated UI for assisted resolution when automatic merging isn't safe.

3. Technical Approach

  • Architecture or components involved: The engine will use a "Base" version (last synchronized), a "Local" version, and a "Remote" version to perform the merge.

  • Changes to the Joplin codebase: Integration of the merge engine into the existing synchronization workflow at the point where conflicts are detected.

  • Libraries or technologies you plan to use: TypeScript based diff libraries (e.g Myers diff algorithm) and heuristics to preserve list structures and headings.

  • Potential challenges: Managing overlapping edits and ensuring the system never discards user changes by falling back to assisted resolution.

4. Implementation Plan

  • Weeks 1–2: Analyze current conflict detection, define data flows, and prototype the initial merge engine with unit tests.

  • Weeks 3–5: Implement three-way merge logic and integrate the engine with the synchronization process.

  • Weeks 6–7: Improve merge quality for markdown (lists, headings) and optimize performance for large notes.

  • Weeks 8–9: Design and implement the shared TypeScript ui for assisted conflict resolution.

  • Weeks 10–12: Extensive testing of edge cases, code cleanup, and finalization of documentation.

5. Deliverables

  • Implemented features: An automatic conflict detection/merging engine and a cross-platform assisted resolution interface.

  • Tests: A suite of unit and integration tests covering simultaneous edits, large notes, and structured Markdown.

  • Documentation: Developer guides for the merge algorithm and updated user documentation for the new workflow.

6. Availability

  • Weekly availability: Full-time commitment of approximately 40 hours per week for the duration of the summer.

  • Time zone: Based in Italy (CET/CEST) but flexible to adapt to mentors' needs.

  • Other commitments: Three isolated university exam days, with work redistributed to compensate.

1 Like
2

Thank you for the draft submission!

The @codemirror/merge library might be useful for the "Assisted Conflict Resolution" part of the project (Joplin's Markdown editor currently uses CodeMirror 6).

3

Thanks for the suggestion, I had missed this CodeMirror module.

1 Like
4

I had a read through the proposal and there is one particular thing which is an issue with the implementation:

In this project, when such a situation is detected, the system will instead perform a
three-way merge using:

  • Base version: the last synchronized version of the note
  • Local version: the note modified on the current device
  • Remote version: the version retrieved from the sync target

The base version can be reconstructed using the revision history already available in
Joplin’s synchronization and note history mechanisms.

3 way merge is definately the logical way to go, but you can’t rely on revision history to reconstruct the base version. First of all, there is no guarantee that the user has enabled note history, and second of all the revision collection is restricted to only producing revisions once every 10 minutes. So they’re not suitable for this purpose. You’ll need to find another way to obtain the base version of a note.

You’ve already proposed modifying the synchronizer logic (but not interrupting the sync) to integrate automatic conflict resolution where possible, which I think is probably ok. But I think in order to obtain a base version, you will need to add some logic to the upload step of the synchronizer, to store a base version of a note somewhere in the local database at the point of uploading a change to the server (only when the upload could be completed, ie. there is no conflict or the conflict has been automatically resolved). I think the most logical place to store it would be a new column on the sync_items table.

5

Thank you for your feedback, I'm thinking through the best way to incorporate these changes to ensure the proposal is as effective as possible.

6

Rather than repeating myself, I’ll just link the other proposal for this project, which details some important considerations to consider, noted in the comments, in particular this comment: GSoC 2026 Proposal Draft – Idea 9: Automatic Conflict Resolution – Sriram Varun Kumar - #13 by mrjo118

1 Like