Skip to content

feat: add segmentation spec#91

Merged
igor-sirotin merged 24 commits into
masterfrom
feat/segmentation-spec
May 5, 2026
Merged

feat: add segmentation spec#91
igor-sirotin merged 24 commits into
masterfrom
feat/segmentation-spec

Conversation

@plopezlpz
Copy link
Copy Markdown
Contributor

@plopezlpz plopezlpz commented Oct 19, 2025

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

Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Copy link
Copy Markdown
Contributor

@jm-clius jm-clius left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a few comments below, none of them major. Thanks!

Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Copy link
Copy Markdown
Contributor

@jazzz jazzz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread standards/application/segmentation.md Outdated
### 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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the motivation for padding to segment size? I can see this being beneficial in some cases, but curious what makes it required?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Padding is a requirement of Reed-Solomon, all segments must be of the same size

Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Copy link
Copy Markdown
Contributor

@fryorcraken fryorcraken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can and should make the spec mostly Waku agnostic. Waku can still be mentioned in the motivation.

Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
@plopezlpz plopezlpz requested a review from jm-clius October 27, 2025 08:11
Comment thread standards/application/segmentation.md
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md
Comment thread standards/application/segmentation.md Outdated
@igor-sirotin
Copy link
Copy Markdown
Contributor

@plopezlpz please address the comments and let's get this merged 🚢
This holds the closing of Deliverable

Copy link
Copy Markdown
Contributor

@jm-clius jm-clius left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread standards/application/segmentation.md Outdated
@jazzz jazzz mentioned this pull request Feb 9, 2026
@igor-sirotin igor-sirotin self-assigned this Apr 23, 2026
@igor-sirotin igor-sirotin force-pushed the feat/segmentation-spec branch from 0ff0c97 to bef0d20 Compare April 28, 2026 20:56
@igor-sirotin igor-sirotin requested review from jazzz and osmaczko April 28, 2026 20:59
@igor-sirotin igor-sirotin moved this to Code Review / QA in Logos Delivery Apr 28, 2026
@igor-sirotin igor-sirotin requested a review from jm-clius April 28, 2026 21:23
Comment thread standards/application/segmentation.md Outdated
Copy link
Copy Markdown
Contributor

@jm-clius jm-clius left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is good to merge now! Thanks. I'd say future updates can be done in follow-up PRs. Minor comments below.

Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated

- `entire_message_hash.length == 32`
- **Data segments:**
`segments_count >= 1` **AND** `index < segments_count`
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

@igor-sirotin igor-sirotin Apr 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jm-clius it's defined here:

- `maxTotalSegments` — maximum number of total shards (data + parity) per message.
Implementation-specific parameter, fixed. The reference implementation uses **256**.

Or do you think we should introduce hard limits for implementations on spec level 🤔

Comment thread standards/application/segmentation.md Outdated
Copy link
Copy Markdown
Contributor

@Ivansete-status Ivansete-status left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some nits so far

Comment thread standards/application/segmentation.md
Comment thread standards/application/segmentation.md
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
Copy link
Copy Markdown
Contributor

@jazzz jazzz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread standards/application/segmentation.md Outdated
Comment thread standards/application/segmentation.md Outdated
@igor-sirotin
Copy link
Copy Markdown
Contributor

Here's what I'll change:

  1. Forget about Status implementation. We're writing a new thing for ourselves.
  2. Require wrapping single-segment messages (i.e. segments_count >= 1)
  3. Remove Backwards Compatibility section
  4. Add is_parity proto field instead of segment_count=0 as implicit sign of parity shards. Adding 2 bytes is not harmful, but brings clarity.

@igor-sirotin igor-sirotin requested a review from osmaczko April 30, 2026 14:24
@igor-sirotin igor-sirotin force-pushed the feat/segmentation-spec branch from 34085c0 to 786f111 Compare May 5, 2026 22:07
@igor-sirotin
Copy link
Copy Markdown
Contributor

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.

@igor-sirotin igor-sirotin merged commit 63aa0d3 into master May 5, 2026
1 check passed
@igor-sirotin igor-sirotin deleted the feat/segmentation-spec branch May 5, 2026 22:11
@github-project-automation github-project-automation Bot moved this from Code Review / QA to Done in Logos Delivery May 5, 2026
igor-sirotin added a commit to logos-co/logos-lips that referenced this pull request May 28, 2026
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

9 participants