docs/REQUEST_SYNC_MANAGER.md
This document details the implementation of the Request Sync Manager and updates to the V2 packet structure to improve synchronization security and attribution on iOS, mirroring the Android implementation.
The goal of these changes is to make the request sync functionality "less blind". Previously, sync requests were broadcast, and responses were accepted without strict attribution or timestamp validation (to allow syncing old messages). This opened up potential spoofing vectors and prevented us from enforcing timestamp checks on normal traffic.
The new implementation introduces a RequestSyncManager to track outgoing sync requests and attributes incoming responses (RSR - Request-Sync Response) to specific peers. This allows us to:
IS_RSR (0x10) added to the packet header flags.isRSR: Bool field.BinaryProtocol to handle the new flag.The REQUEST_SYNC packet payload (TLV encoded) has been updated to include:
sinceTimestamp (Type 0x05): To request packets since a certain time (UInt64 big-endian).fragmentIdFilter (Type 0x06): To request specific fragments (UTF-8 string).A new component (Sync/RequestSyncManager.swift) responsible for:
peerID -> timestamp mappings for pending sync requests.isValidResponse(from: PeerID, isRSR: Bool) checks if an incoming RSR packet matches a pending request within the 30-second window.REQUEST_SYNC packets.RequestSyncManager.REQUEST_SYNC, generated packets (Announce/Message) are explicitly marked with isRSR = true (and ttl = 0).abs(now - packetTimestamp) < 2 minutes for standard packets.packet.isRSR is true (or packet is a legacy TTL=0 response), it queries RequestSyncManager.
These changes are integrated into BLEService and GossipSyncManager. No external API changes are required for clients, but all peers must be updated to support the new IS_RSR flag and protocol logic to participate in the secure sync process.