Conflict Resolution Protocol¶

Nube ensures data preservation is absolute. This document outlines the conflict detection logic and the resolution strategy used by the SyncManager.

Core Axiom¶

“Data Preservation is Absolute.” Under no circumstances must a remote change be overwritten by an unaware local change.

Detection Logic¶

Calculate Hash: Hash(Local_File)
Identify Basis: Parent_Hash (the state of the local file at the time editing began).
Check Remote Head: - If DAG_Head == Parent_Hash: Clean Write (fast-forward update of the remote reference). - If DAG_Head != Parent_Hash: CONFLICT (divergent modifications detected).

Traceability: Implements [FUNC-SYNC-FABRIC] and [FUNC-DYNAMIC-SHARING]. Identifier: [TECH-CONFLICT-CRP]

Resolution Strategy (The “Sidecar”)¶

When a conflict is detected: #. Upload: The Local_File content is uploaded immediately to the blockstore. #. Rename (Local): The local filesystem file File A.ext is renamed to File A (Conflict [User] [Timestamp]).ext. #. Download: The DAG_Head (remote version) is downloaded and written to File A.ext. #. Notify: A real-time notification is sent via the SSE broker to alert the user via the Web UI.

The “Zombie” Edge Case¶

If a node crashes while holding a lock on a shared directory/file, upon daemon restart: - The client attempts to acquire the lock. - The lock request is denied if the file has been modified by another peer in the meantime. - The client triggers the Sidecar Strategy immediately to prevent data loss.