use keccak-256 instead of arbitrary random num when processing SDS msg

This commit is contained in:
Ivan FB 2026-05-01 11:24:38 +02:00
parent a6fd069eeb
commit 491b2e36d1
No known key found for this signature in database
GPG Key ID: DF0C67A04C543270

View File

@ -109,7 +109,7 @@ See [SEGMENTATION](./segmentation.md).
[SDS](https://lip.logos.co/ift-ts/raw/sds.html) provides end-to-end delivery guarantees using causal history tracking.
- Each new segment to be sent, requires the following data:
- `MessageId`: a 40-character random hex string (e.g. `a23f89b4df7e1ba5a709352da3a247a4fd609f4c`), generated by the Reliable Channel API.
- `MessageId`: a keccak-256([message](https://lip.logos.co/ift-ts/raw/sds.html#message)'s content) hex string (e.g. `4e03657aea45a94fc7d47ba826c8d667c0d1e6e33a64a036ec44f58fa12d6c45`), generated by the Reliable Channel API.
- `ChannelId`: the `channelId` passed to `createReliableChannel`.
- Retrieval hint: the transport `MessageHash` of previous segments, exposed by the underlying [MESSAGING-API](/standards/application/messaging-api.md) upon ``MessageSendPropagatedEvent` reception.
The hint provider registered during [Node initialization](#node-initialization) performs this `MessageId → MessageHash` lookup. In turn, that mapping MUST be persisted by SDS using the `persistence` backend configured in `SdsConfig`.