docs: Reliable Channel API spec#104
Conversation
82301c3 to
d4690df
Compare
| - The `IEncryption` interface MUST be implemented by the caller (e.g., the Chat SDK). | ||
| - The Reliable Channel API MUST NOT impose any specific encryption scheme. | ||
|
|
||
| ## Security/Privacy Considerations |
There was a problem hiding this comment.
SDS Contains a senderID, depending on how this will be implemented there is a potential privacy issue with unencrypted public reliability.
[Dust] Add privacy implications for unencrypted reliability
There was a problem hiding this comment.
Good point! Should we always encrypt the channelId to avoid privacy concerns? We can have a simple/fix encryption for that, without ratcheting in this particular case. wdyt?
There was a problem hiding this comment.
Should we always encrypt the channelId to avoid privacy concerns?
- Who would have access to this key?
- How do you get the key to them?
Answering these questions has a major impact on UX. If it work for your use case, its easy enough to derive an encryption keym but depends heavily on the required security level
jazzz
left a comment
jazzz
left a comment
There was a problem hiding this comment.
Diving deeper into this, I think some extra clarity around Encryption would be helpful.
I'm unsure if the goal is:
- Encrypt the channel_id so observers cannot correlate channel activity.
- Provide payload confidentiality
- Segmentation header encryption to obscure payload sizes
- All of the above
This makes it hard to evaluate the proposed approach. Being clear around the goals and motivations would make it clearer for readers.
but does not provide high end-to-end delivery guarantees from sender to recipient.
This suggests the purpose of RChans is purely reliability, in which case I would ask why does there need to be Encryption at all? Or segmentation? Spending time to clearly capture the goals would make it easier for developers to know how to use this object
|
(I cannot answer inline in this case) |
|
The commit a267622 adds some more ideas from @fryorcraken in #89 ( I just realised about the 89 after creating this one .) |
Co-authored-by: Igor Sirotin <igor.sirotin.1012@gmail.com>
Co-authored-by: Igor Sirotin <igor.sirotin.1012@gmail.com>
Co-authored-by: Igor Sirotin <igor.sirotin.1012@gmail.com>
…tore node" This reverts commit 01cf30d.
jazzz
left a comment
jazzz
left a comment
There was a problem hiding this comment.
This has seen some real improvement since the last time i reviewed it.
It's become clearer, and there is more of the details that I would want to see.
There are no blocking comments in this review - despite there being many - You can merge when ever you want. Though I'd like to know the plan for addressing the pebbles.
| category: Standards Track | ||
| status: raw | ||
| tags: [reliability, application, api, sds, segmentation] | ||
| editor: Logos Messaging Team |
There was a problem hiding this comment.
[Dust] While not strictly forbidden by 1/COSS. My understanding was multiple editors adds ambiguity to the process. "Who is responsible for changes?", "what if team members disagree?" Choosing a single person responsible for managing the lifecycle of the document, avoids the "diffusion of responsibility"
There was a problem hiding this comment.
ah okay, addressed now
There was a problem hiding this comment.
- Igor Sirotin sirotin@status.im
- Jazz Turner-Baggs jazz@status.im
- Ivan Folgueira Bande ivansete@status.im
This is more the specs team area of expertise.
However: I think you want a single editor, with multiple Contributors. The editor is just the person who is responsible for responding to updates. This can be sorted out later when it gets pushed to Logos-Lips
| description: "Decrypts a byte payload. Returns the decrypted payload." | ||
| parameters: | ||
| - name: payload | ||
| type: array<byte> | ||
| returns: | ||
| type: result<array<byte>, error> |
There was a problem hiding this comment.
[Pebble] How are developers supposed to determine if decryption was successful?
If all that is receive is a byte array, and there are multiple encryption keys (because I have multiple reliable channels) - How do I determine I found the right key?
I as the developer have no idea what the payload structure should be because its generated internally. Each decryption will result in a seemingly random series of bytes, If I don't know what I should be expecting.
There was a problem hiding this comment.
We will tackle that in a separate PR, in lips
| - name: content | ||
| type: array<byte> | ||
| returns: | ||
| type: result<array<byte>, error> |
There was a problem hiding this comment.
[Sand] What error type is returned from the encryption function?
There was a problem hiding this comment.
Same. Let's enhance once in lips.
| 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 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). |
There was a problem hiding this comment.
[Sand] It would be helpful to explain, that this is what the MessageHash is for.
The MessageId → MessageHash mapping is never really explained
jazzz
left a comment
jazzz
left a comment
There was a problem hiding this comment.
I see there are now plans for the remaining Pebbles. 🚀
4 participants
This PR aims to gather the initial Reliable Channel API spec, inspired by the following forum post:
Related Issue