GSoC 2026 Proposal Draft – Idea 9: LAN Sync – Kareem Abu Al Enein

GSoC GSoC Proposal Drafts
1

Links

Introduction

My name is Kareem Abu Al Enein, and I am a recent Computer Engineering graduate from Cairo University, Egypt. I am passionate about building systems that solve real-world problems.

I have hands-on experience developing scalable applications using technologies such as Node.js, FastAPI, PostgreSQL, and Docker. During my internship at Sherkety, I worked on building and maintaining APIs, integrating third-party services, and implementing payment systems, which strengthened my understanding of production-level software development.

I have also worked on a variety of projects, including a secure chat application implementing cryptographic protocols (Diffie-Hellman, AES), and a real-time social platform with WebSocket-based communication. These experiences helped me build a solid foundation in networking concepts, system design, and performance considerations.

I am particularly interested in the LAN Sync project, as it lies at the intersection of networking and software engineering—areas I am currently deepening my knowledge in through hands-on practice and Cisco networking courses.

Project Summary

Problem

Current Joplin sync targets are primarily cloud/server oriented. Users who want offline, local-network-first sync need a simpler LAN-native workflow.

What will be implemented (from my point of view - open for suggestions)

  1. LAN onboarding methods
    • Auto-discovery (mDNS)
    • Host mode with QR
    • Invite link pairing
  2. LAN connectivity layer
    • Endpoint discovery and reachability checks
    • Manual endpoint fallback (IP:port) when discovery fails
  3. Sync integration path
    • LAN target/transport wired into existing sync architecture
    • Keep core Synchronizer behavior unchanged

Technical Approach

1) First: Feasibility check (before real sync code)

Build a small LAN test service to confirm:

  • Devices can reach each other on LAN
  • Discovery can find peers and remove them when offline

2) Shared LAN base (packages/lib/services/lan/*)

Create shared types/interfaces so desktop and mobile behave the same.

3) Auto-discovery method

Use same discovery interface on desktop and mobile.
Convert mDNS data to one common internal format.

4) Host + QR/manual method

Host generates one pairing payload with:

  • endpoint URL
  • token
  • expiry

QR and manual text both use this same payload.

5) Invite link method

Extend callback URL handling to accept LAN pairing payload.
Use the same validation logic as QR payload (single validator for both).

6) Settings

Add LAN settings for:

  • discovery enabled
  • host/client mode
  • listen port
  • manual endpoint
  • token (securely stored)

7) LAN sync integration

After feasibility is confirmed:

  • Add SyncTargetLan
  • Add LAN file API driver
  • Register target and connect it to existing sync flow

8) Security

  • Token required for protected LAN routes
  • Never log full tokens or show them in error logs

Implementation Plan

Weeks 1–2: Feasibility gate

  • Build probe endpoint + probe runner
  • Test desktop host ↔ mobile client
  • Test mobile host ↔ desktop client
  • Test discovery on router LAN and hotspot
  • Test manual endpoint fallback

Weeks 3–4: Shared contracts + settings

  • Add LAN types/interfaces + pairing codec + validator
  • Add LAN settings metadata and secure token storage
  • Add basic config UI fields

Weeks 5–6: Auto-discovery

  • Implement discovery adapters
  • Add peer list picker
  • Save selected peer

Weeks 7–8: Host + QR/manual

  • Implement host start/stop lifecycle
  • Generate pairing payload
  • Show QR and copyable manual details
  • Add mobile scanner using same validator

Weeks 9–10: Invite link

  • Extend callback URL parsing/routing
  • Handle expired/invalid links cleanly

Weeks 11–12: LAN sync integration

  • Add SyncTargetLan + LAN file API driver
  • Register target
  • Run compatibility checks (locks, conflicts, deletes, E2EE)

Final buffer

  • Address mentor feedback
  • Finalize docs
  • Prepare final deliverables

Availability

  • Weekly availability: 40 hours/week

    Time zone: UTC+2

  • Other commitments: working on my project ARISE · GitHub

I am currently studying the plan in more depth to provide a stronger system architecture and more detailed implementation breakdown. In parallel, I am continuing to familiarize myself with the Joplin codebase.

1 Like