From ac4883fa15c21816a0a962a3eeee9ea6a3f5dac8 Mon Sep 17 00:00:00 2001 From: Ivan FB Date: Fri, 1 May 2026 17:57:36 +0200 Subject: [PATCH] better explain why hint provider is needed. --- standards/application/reliable-channel-api.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/standards/application/reliable-channel-api.md b/standards/application/reliable-channel-api.md index e70ee87..3439a5a 100644 --- a/standards/application/reliable-channel-api.md +++ b/standards/application/reliable-channel-api.md @@ -170,7 +170,7 @@ When a segment is received from the network, the implementation MUST process it 1. **Decrypt**: If an `Encryption` implementation is provided, decrypt the segment. 2. **Apply [SDS](https://lip.logos.co/ift-ts/raw/sds.html)**: Deliver the segment to the SDS layer, which emits acknowledgements and detects gaps. - - **Detect missing dependencies**: If SDS detects a message in the causal history which has not yet been received, it MUST make a best-effort attempt to retrieve the missing message, and MAY use the store protocol internally for this purpose. If the message cannot be retrieved, SDS MAY mark it as lost. + - **Detect missing dependencies**: If SDS detects a gap in the causal history, it MUST make a best-effort attempt to retrieve the missing message. The `Retrieval hint` (see [Scalable Data Sync (SDS)](#scalable-data-sync-sds)) carried in each SDS message provides the transport `MessageHash` needed to query the store; without it, store retrieval is not possible. If the message cannot be retrieved, SDS MAY mark it as lost. 3. **Reassemble**: Once all segments for a message have been received, reassemble and emit a `reliable:message:received` event. ### Rate limiting