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

avoid using the term logos chat

Browse Source
This commit is contained in:
Ivan FB 2026-04-23 21:47:51 +02:00
parent f8156d4c2a
commit b2ecac4ad5
No known key found for this signature in database
GPG Key ID: DF0C67A04C543270
1 changed files with 5 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -41,7 +41,7 @@ editor: Logos Messaging Team
## Abstract
This document specifies the **Reliable Channel API**,
an application-level interface that sits between the Logos Chat and the [MESSAGING-API](/standards/application/messaging-api.md) plus [P2P-RELIABILITY](/standards/application/p2p-reliability.md), i.e., `logos-chat` <-> **reliable-channel-api** <-> `messaging-api/p2p-reliability`.
an application-level interface that sits between the application layer and the [MESSAGING-API](/standards/application/messaging-api.md) plus [P2P-RELIABILITY](/standards/application/p2p-reliability.md), i.e., `application` <-> **reliable-channel-api** <-> `messaging-api/p2p-reliability`.
It bundles segmentation, end-to-end reliability via [Scalable Data Sync (SDS)](https://lip.logos.co/ift-ts/raw/sds.html), rate limit management, and a pluggable encryption hook
into a single interface for sending and receiving messages reliably.
@ -56,7 +56,7 @@ This API addresses that gap by introducing:
- **Segmentation** to handle large messages exceeding network size limits.
- **SDS** to provide causal-history-based end-to-end acknowledgement and retransmission.
- **Rate Limit Manager** to comply with [RLN](https://lip.logos.co/messaging/standards/core/17/rln-relay.html) constraints when sending segmented messages.
- **Encryption Hook** to allow upper layers (e.g., the Logos Chat) to provide a pluggable encryption mechanism. The main motivation for encryption is to protect the payload and content_topic from MessageEnvelope, defined in [MESSAGING-API](/standards/application/messaging-api.md).
- **Encryption Hook** to allow upper layers to provide a pluggable encryption mechanism. The main motivation for encryption is to protect the payload and content_topic from MessageEnvelope, defined in [MESSAGING-API](/standards/application/messaging-api.md).
The separation between Reliable Channels and encryption ensures the API remains agnostic to identity and key management concerns,
which are handled by higher layers.
@ -74,12 +74,11 @@ A custom Interface Definition Language (IDL) in YAML is used, consistent with [M
### Architectural position
The Reliable Channel API sits between the Logos Chat and the Messaging API, as follows:
The Reliable Channel API sits between the application layer and the Messaging API, as follows:
```
┌────────────────────────────────────────────────────────────┐
│ Logos Chat │
│ (Identity + Encryption + UX) │
│ Application Layer │
└───────────────────────────┬────────────────────────────────┘
│
┌───────────────────────────▼────────────────────────────────┐
@ -514,7 +513,7 @@ The Encryption Hook provides a pluggable interface for upper layers to inject en
- The hook is optional; when not provided, messages are sent as plaintext.
- Encryption is applied per chunk, after segmentation and SDS registration.
- Decryption is applied per chunk, before SDS delivery.
- The `IEncryption` interface MUST be implemented by the caller (e.g., the Logos Chat).
- The `IEncryption` interface MUST be implemented by the caller.
- The Reliable Channel API MUST NOT impose any specific encryption scheme.
## Security/Privacy Considerations