logos-messaging/specs
1
0
Fork 0
mirror of https://github.com/logos-messaging/specs.git synced 2026-05-19 03:19:33 +00:00
Code Issues Packages Projects Releases Wiki Activity

add node initialization procedure

Browse Source
This commit is contained in:
Ivan FB 2026-04-29 14:14:16 +02:00
parent 493b909f02
commit 1500a0536d
No known key found for this signature in database
GPG Key ID: DF0C67A04C543270
2 changed files with 29 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
standards/application/messaging-api.md
View File

@ -344,6 +344,15 @@ If the `mode` set is `core`, the initialised `WakuNode` SHOULD use:
`edge` mode SHOULD be used if node functions in resource restricted environment,
whereas `core` SHOULD be used if node has no strong hardware or bandwidth restrictions.
**Fetching missed messages on startup**:
The node MUST persist the timestamp of the last message it successfully received or sent before going offline.
After the node is started and subscriptions are set up, the node SHOULD query the
[STORE](https://lip.logos.co/messaging/standards/core/13/store.html) protocol to retrieve messages
missed while offline, scoped to the subscribed content topics and using the persisted timestamp as the
lower bound of the query.
### Messaging
#### Messaging type definitions

21
standards/application/reliable-channel-api.md
View File

@ -18,6 +18,7 @@ editor: Logos Messaging Team
* [Architectural position](#architectural-position)
* [IDL](#idl)
* [Procedures](#procedures)
* [Node initialization](#node-initialization)
* [Outgoing message processing](#outgoing-message-processing)
* [Incoming message processing](#incoming-message-processing)
* [Rate limiting](#rate-limiting)
@ -95,6 +96,20 @@ A custom Interface Definition Language (IDL) in YAML is used, consistent with [M
## Procedures
### Node initialization
When a node is created via `createNode` (defined in [MESSAGING-API](/standards/application/messaging-api.md)),
the implementation MUST perform the following setup before the node is used:
1. **Configure SDS persistence**: Supply the `Persistence` backend from `SdsConfig` to the SDS module so that
causal history and outgoing buffers survive restarts.
2. **Configure SDS hint provider**: Register a hint provider with the SDS module.
The hint provider converts an SDS `MessageId` into its corresponding `MessageHash`.
3. **Configure Segmentation persistence**: Supply the `Persistence` backend from `SegmentationConfig` to the
[Segmentation](./segmentation.md) module so that partially reassembled messages survive restarts.
4. **Fetch missed messages**: Retrieve messages missed while offline as described in
[MESSAGING-API — Fetching missed messages on startup](/standards/application/messaging-api.md#init-node-extended-definitions).
### Outgoing message processing
When `send` is called, the implementation MUST process `message` in the following order:
@ -310,12 +325,16 @@ types:
type: bool
default: false
description: When enabled, the message sender adds parity (redundant) segments to allow recovery in case of data segment loss. See [SEGMENTATION](./segmentation.md).
segmentSizeBytes:
type: uint
default: 102400 # 100 KiB
description: "Maximum segment size in bytes.
Messages larger than this value are split before SDS processing."
persistence:
type: Persistence
description: "Backend for persisting partial reassembly state across restarts.
Implementations MUST use this backend to store received segments until all segments of a message have arrived and can be reassembled.
Refer to [SEGMENTATION](./segmentation.md) for the full definition of what state must be persisted."
SdsConfig:
type: object