GSoC 2026 Proposal Draft – Idea 10: Automatic Conflict Resolution – Manvendra Kumar Singh

GSoC GSoC Proposal Drafts
1

**

GSoC 2026 Proposal Draft – Idea 10: Automatic Conflict Resolution – Manvendra Kumar Singh**

Links

1. Introduction

I am a B.Tech student in Computer Science and Engineering with experience in TypeScript, React, Node.js, and system design-oriented development.

I have completed an internship as a Software Development Engineer Intern at Paytm Money, where I gained industry experience working on production-grade systems and large-scale applications. This exposure helped me understand system reliability, performance considerations, and real-world engineering practices.

I have also worked on multiple projects such as Chatbuzz, AgriPredict-AI, and TripGenie, including projects involving AI/ML-based systems. Alongside this, I have been actively contributing to open-source projects including Joplin, AOSSIE (EduAid), Rocket.Chat, OpenMRS, and FOSSASIA.

While working with Joplin, I explored key components such as Synchronizer.ts, handleConflictAction.ts, and note lifecycle handling, which gave me a clear understanding of how synchronization and conflicts are currently managed. My interests lie in distributed systems, merge algorithms, and scalable system design, and I aim to build a robust conflict resolution system that improves usability while maintaining strict guarantees around data integrity.

2. Project Summary

Problem

Joplin currently resolves conflicts by duplicating notes into a Conflicts notebook. While this guarantees data safety, it introduces several challenges:

  • Manual comparison of entire notes

  • No assistance for resolving independent edits

  • Poor scalability for long notes

  • Difficult experience on mobile devices

Many conflicts arise from non-overlapping edits, which could be handled more efficiently with structured assistance.

Why it matters

As an offline-first application, Joplin frequently encounters conflicts. Improving this system:

  • Reduces manual effort

  • Improves user trust in synchronization

  • Enhances cross-device usability

  • Scales better for large notes

Proposed Solution

This project introduces a structured conflict resolution system consisting of:

  • A deterministic merge engine

  • A conflict session model

  • A section-based assisted resolution interface

Instead of merging automatically, the system:

  • Identifies safe and conflicting regions

  • Presents structured resolution options

  • Requires explicit user confirmation before applying changes

Expected Outcome

  • Efficient conflict resolution workflow

  • Improved UX on desktop and mobile

  • Safe handling of all note types

  • Scalable architecture for future enhancements

Out of Scope

  • Fully automatic merging without user interaction

  • Special handling for encrypted notes

  • Blocking synchronization during resolution

3. Technical Approach

3.1 Design Principles

  • Safety-first: no silent or automatic merges

  • User-controlled resolution: all changes require explicit confirmation

  • Non-blocking sync: resolution is decoupled from synchronization

  • Backward compatibility: supports notes without base versions

3.2 System Architecture

The system follows a layered approach similar to structured system designs:

Conflict Detection (Sync Layer)

→ Conflict Session Initialization

→ Merge Engine (Analysis Layer)

→ Resolution UI (Presentation Layer)

→ Final Commit (User Action)

This separation ensures modularity and extensibility.

3.3 Integration with Joplin

  • Synchronizer.ts → detects conflicts

  • handleConflictAction.ts → creates conflict notes

  • Merge engine → processes note versions

  • UI layer → resolves conflicts

Existing behavior remains unchanged and is extended safely.

3.4 Merge Engine Design

The merge engine is a reusable module:

packages/lib/services/conflict/mergeEngine.ts

Inputs:

  • Base version (optional)

  • Local version

  • Remote version

Outputs:

  • Structured conflict sections

  • Classification metadata

  • Preview plan

3.5 Merge Strategy

The system uses:

  • Line-based diffing for efficiency

  • Section-based grouping for usability

Classification Rules:

Scenario

Result

identical content

safe

local-only change

safe

remote-only change

safe

both modified differently

conflict

no base available

conflict

3.6 3-Way and 2-Way Handling

  • 3-way merge: used when base version is available

  • 2-way fallback: used when base is missing

In 2-way mode:

  • All differences are treated conservatively

  • No assumptions are made about safe merges

3.7 Conflict Data Model

type ConflictSection = {

index: number;

startLine: number;

endLine: number;

lineRangeBasis: "base" | "local";

type: "safe" | "conflict";

reason: string;

base?: string;

local: string;

remote: string;

};

This enables:

  • precise UI highlighting

  • section-level resolution

  • progress tracking

3.8 Conflict State Management

Instead of relying on history, conflict state is stored explicitly:

  • conflict_base_body

  • conflict_remote_body

  • corresponding title fields

These fields are updated incrementally during resolution, ensuring:

  • deterministic state tracking

  • support for undo/redo

  • consistency across sessions

3.9 Assisted Resolution UI

The UI is designed around sections, not lines, aligning with mentor feedback.

Features:

  • Section-based resolution blocks

  • Actions:

    • Use Local

    • Use Remote

    • Edit Manually

  • Bulk resolution for safe sections

  • Context viewer (full note navigation)

  • Dedicated undo/redo controls

3.10 Sync Behavior

  • Conflict resolution does not block synchronization

  • Conflict state remains local

  • Final merge is applied only after user confirmation

3.11 Edge Cases

  • Missing base versions

  • Remote updates during resolution

  • Large notes

  • Multiple conflict sections

  • Title vs body conflicts

3.12 Testing Strategy

  • Unit tests for merge logic

  • Integration tests for sync behavior

  • UI tests for resolution workflows

  • Regression testing

3.13 Documentation

  • Developer documentation (architecture, APIs)

  • User documentation (resolution workflow)

4. Implementation Plan

Community Bonding

  • Study Joplin sync lifecycle

  • Validate architecture with mentors

  • Finalize merge engine design

Weeks 1–2

  • Implement 3-way merge

  • Implement 2-way fallback

  • Section grouping logic

  • Unit testing

Weeks 3–4

  • Integrate with sync layer

  • Base snapshot handling

  • Conflict session initialization

Weeks 5–6

  • Desktop conflict resolution UI

  • Section rendering

  • Resolution actions

Weeks 7–8

  • Resolution completion logic

  • Undo/redo system

  • Midterm evaluation

Weeks 9–10

  • Mobile UI implementation

  • Cross-platform consistency

Weeks 11–12

  • Performance optimization

  • Testing and documentation

  • Final refinements

5. Deliverables

  • Merge engine module

  • Conflict session system

  • Desktop and mobile UI

  • Sync integration

  • Test suite

  • Documentation

6. Proof of Concept (PoC)

To validate the merge logic, I implemented a TypeScript-based merge engine prototype.

Features:

  • 3-way merge (base, local, remote)

  • 2-way fallback

  • Section-based grouping

  • Deterministic classification

  • Structured JSON output with positional context

  • Preview plan for UI rendering

Purpose:

  • Validate merge behavior independently

  • Demonstrate feasibility of system design

  • Provide UI-consumable output

Demo:

7. Availability

  • 30 hours per week

  • Timezone: IST (UTC+5:30)

  • Active communication with mentors on a weekly basis

Final Note

This proposal focuses on building a safe, structured, and scalable conflict resolution system that integrates naturally with Joplin’s architecture while improving usability without compromising data integrity.

AI Assistance Disclosure

I used AI to help with grammar and wording while writing this proposal. The technical content, architecture decisions, and code are all my own. I also used it to go through a lot of research material.