make more concise substep in sds in msgs

This commit is contained in:
Ivan FB 2026-04-28 22:33:31 +02:00
parent a23f89b4df
commit 76ccd41549
No known key found for this signature in database
GPG Key ID: DF0C67A04C543270

View File

@ -111,8 +111,8 @@ 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.
- **2.1. Detect missing dependencies**: If SDS detects a gap in the causal history (i.e., a referenced predecessor segment has not yet been received), the implementation MUST attempt to retrieve the missing segment.
- **2.2. Fetch from store**: The implementation MUST provide a mechanism to extract a retrieval hint from the received segment (e.g., a store cursor or message hash embedded in the SDS causal history). The missing segment MUST then be fetched from a store node via the [MESSAGING-API](/standards/application/messaging-api.md) store query, and re-injected into the incoming processing pipeline from step 1.
- **Detect missing dependencies and fetch from store**: If SDS detects a gap in the causal history (i.e., a referenced predecessor segment has not yet been received), and considers the message is irretrievably lost,
the implementation MUST attempt to retrieve the missing segment throughout store protocol (store API is never exposed and hence, store queries are handled internally).
3. **Reassemble**: Once all segments for a message have been received, reassemble and emit a `reliable:message:received` event.
### Rate limiting
@ -285,7 +285,6 @@ types:
Returned by `createReliableChannel` and used to send messages and receive events.
Internal state (SDS, segmentation, encryption) is managed by the implementation."
MessageEvents:
type: event_emitter
description: "Event source for reliable message events on a channel"