[feature] Local synchronization orchestration for single-member sessions

[paul-fresquet]

Summary

Currently, ByteSync already supports local data transfer (files transfer locally without cloud upload), but the synchronization orchestration (coordination, progress tracking, state management) still goes through the cloud server. This enhancement proposes implementing local synchronization orchestration when a session has only one member, while keeping the cloud server for session creation and member state updates.

Context

What works today:

• ✅ Session creation via cloud (remains unchanged)
• ✅ Local data transfer between Data Sources (\SynchronizationActionHandler.RunCopyContentLocal)
• ✅ Full end-to-end encryption
• ✅ Smart delta transfers using FastRsync

What still requires server orchestration:

• ❌ Synchronization start coordination (\StartSynchronizationRequest\ → \StartSynchronizationCommandHandler)
• ❌ Action completion tracking (\LocalCopyIsDone, \RemoteCopyIsDone\ API calls)
• ❌ Progress updates (SignalR push notifications)
• ❌ Synchronization state management (Redis transactions/locks)

Proposed Enhancement

For single-member sessions, implement local orchestration of the synchronization process:

Scope of this issue:

1. ✅ Detect when session has only one member
2. ✅ Replace server-side synchronization coordination with local state machine
3. ✅ Handle progress tracking in-memory instead of via Redis + SignalR
4. ✅ Skip unnecessary API calls (StartSynchronization, LocalCopyIsDone, etc.)
5. ✅ Continue sending session member state updates to the server
6. ✅ Keep cloud-based session creation and management

Out of scope (future issue):

• ❌ Fully offline session creation
• ❌ Multi-member peer-to-peer synchronization
• ❌ LocalSession implementation

Benefits

• Reduced latency: No round-trip to Azure Functions for each action
• Better resilience: Synchronization works even if cloud has temporary issues (session already created)
• Lower server costs: Reduced Azure Functions calls and Redis operations
• Simpler flow: Direct local orchestration for single-member use case

Technical Implementation

Detection Mechanism

\\csharp
// In SynchronizationStarter or similar
bool isSingleMemberSession = _sessionMemberService.GetSessionMembers().Count == 1;
\\

Components to Modify

1. Synchronization Start (\SynchronizationStarter.cs)

• Detect single-member session
• If single member: skip _synchronizationApiClient.StartSynchronization()\
• Directly invoke local synchronization coordinator

2. Action Completion (\SynchronizationActionServerInformer.cs)

• Skip API calls to \LocalCopyIsDone, \RemoteCopyIsDone\ for single-member
• Update local state directly
• Keep sending session member status to server

3. Progress Tracking

• Create local progress tracker (in-memory)
• Emit local events instead of waiting for SignalR push
• Mirror the server-side \SynchronizationProgressService\ behavior locally

4. State Management

• Implement local equivalent of \TrackingActionEntity\ coordination
• No Redis locks/transactions needed
• Simple in-memory state machine

Key Files to Update

• \src/ByteSync.Client/Services/Synchronizations/SynchronizationStarter.cs\
• \src/ByteSync.Client/Services/Synchronizations/SynchronizationActionServerInformer.cs\
• \src/ByteSync.Client/Services/Synchronizations/SynchronizationLooper.cs\
• Create new: \src/ByteSync.Client/Services/Synchronizations/LocalSynchronizationOrchestrator.cs\

Architecture Decision

Sessions remain CloudSession - We don't reintroduce \LocalSession. The session is still created and managed via the cloud, we're only bypassing cloud orchestration for the synchronization phase when it's unnecessary (single member).

Future Work

After this issue is completed, a separate issue will address:

• Fully offline session creation and management
• Ability to fallback to cloud if needed
• True \LocalSession\ with no internet requirement