feat: add segmentation spec#91
Conversation
jm-clius
left a comment
There was a problem hiding this comment.
I have a few comments below, none of them major. Thanks!
jazzz
left a comment
There was a problem hiding this comment.
Overall, I think the idea has good bones.
message_hash, segment_index, segment_count provide base functionality for segmentation within an encrypted context.
Relaxing some of the implementation constraints would make it easier for other engineers to incorporate this work into their projects.
| ### Reed–Solomon | ||
|
|
||
| Implementations that apply parity **SHALL** use fixed-size shards of length `segmentSize`. | ||
| The last data chunk **MUST** be padded to `segmentSize` for encoding. |
There was a problem hiding this comment.
What is the motivation for padding to segment size? I can see this being beneficial in some cases, but curious what makes it required?
There was a problem hiding this comment.
Padding is a requirement of Reed-Solomon, all segments must be of the same size
fryorcraken
left a comment
There was a problem hiding this comment.
I think we can and should make the spec mostly Waku agnostic. Waku can still be mentioned in the motivation.
|
@plopezlpz please address the comments and let's get this merged 🚢 |
jm-clius
left a comment
There was a problem hiding this comment.
Good job! I think this can be merged once the few outstanding comments are addressed.
In my mind they are:
- make the spec Waku-agnostic (can be mentioned in Motivation section)
- remove "sender public key" and just mention more generically that index can take place by sender as well as entire message hash.
0ff0c97 to
bef0d20
Compare
jm-clius
left a comment
There was a problem hiding this comment.
I think this is good to merge now! Thanks. I'd say future updates can be done in follow-up PRs. Minor comments below.
|
|
||
| - `entire_message_hash.length == 32` | ||
| - **Data segments:** | ||
| `segments_count >= 1` **AND** `index < segments_count` |
There was a problem hiding this comment.
Perhaps wise to also define a maximum segments_count (e.g. 256) here, especially because receivers will allocate an in-memory cache based on expected number of segments.
There was a problem hiding this comment.
@jm-clius it's defined here:
specs/standards/application/segmentation.md
Lines 165 to 166 in 9bcf528
Or do you think we should introduce hard limits for implementations on spec level 🤔
Ivansete-status
left a comment
There was a problem hiding this comment.
Some nits so far
jazzz
left a comment
There was a problem hiding this comment.
Thank you for getting this across the line.
The changes look good, and I think the core here is solid.
My only hang up is that the "Backwards compatibility" section currently has more questions than answers. I would highly recommend removing it for now, and then address it in a follow up.
However I won't block this PR.
|
Here's what I'll change:
|
Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com>
34085c0 to
786f111
Compare
|
I'm gonna merge now. My initial goal was to address the comments in this PR, as it was ready and mostly approved, so I didn't bother much. I agree there're more problems to the current spec. I will address them in separate PRs, after moving it to https://github.com/logos-co/logos-lips. |
Moved SEGMENTATION spec from https://github.com/logos-messaging/specs. Original PR: logos-messaging/specs#91 Changes included: - frontmatter format - convert links - fix RFC2119 terminology styling (`MUST` instead of `**MUST**`) - typos fixed Co-authored-by: Copilot <copilot@github.com>
Added the specs for Application level segmentation of messages to be able to send messages larger than 150kb using Waku by partitioning them at source and reconstructing them on the recipient
Already implemented in https://github.com/waku-org/nim-chat-sdk/blob/main/chat_sdk/segmentation.nim