docs(signal-protocol): document own-device exclusion from sender-key warm mark

[jlucaso1]

What

Updates advanced/signal-protocol.mdx to document whatsapp-rust#999: the group sender-key "warm mark" (update_sender_key_devices) now excludes the account's own companion devices, mirroring WhatsApp Web's !isMeDevice guard on markHasSenderKey.

Why

This closes a residual noted in the existing docs for #996: the warm mark previously recorded the full SKDM distribution target — including own companions — as has_key=true, regardless of whether that device's pairwise encryption actually succeeded. Since the forget path already excludes own devices (to stop an inbound retry receipt from tearing down our own session), an own companion whose one SKDM encryption failed could never be un-marked — a permanent orphan. #999 fixes this by excluding own devices from the warm mark too, so they're never memoized and get a fresh SKDM on every send.

Changes

• Extended the existing <Note> under "Parallelized group encrypt fan-out" (which already chronicled the #996 fix and flagged this exact residual) with a paragraph closing the loop: #999 excludes own devices from the warm mark, closing the orphan window entirely.
• Added a short <Note> under "Incremental targeting" cross-referencing the above, so readers following the has_key diff logic see the own-device exclusion where it's most relevant.

No other guides (group-management.mdx, sending-messages.mdx) reference this internal tracking mechanism, so no other files needed updates. Changelog is intentionally untouched.

Ref: oxidezap/whatsapp-rust#999

---

Generated by Claude Code

---

Summary by cubic

Update Signal Protocol docs to state that the group sender-key warm mark excludes the account’s own companion devices (mirrors WhatsApp Web’s !isMeDevice) and fix a link’s text to match its heading. This prevents orphaned own devices by never marking them has_key=true so they get a fresh SKDM on every send; external members are unaffected.

^{Written for commit 4f5c8f1. Summary will update on new commits.}

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
whatsapp-rust	🟢 Ready	View Preview	Jul 7, 2026, 3:06 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[coderabbitai]

Warning

Review limit reached

@jlucaso1, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 42 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 03ffe98d-8c58-4d64-a32b-ce86581a432b

📥 Commits

Reviewing files that changed from the base of the PR and between 4424afc and 4f5c8f1.

📒 Files selected for processing (1)

• advanced/signal-protocol.mdx

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cubic-dev-ai]

No issues found across 1 file

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

<sub>Auto-approved: Documentation-only change to signal-protocol.mdx explaining own-device exclusion from sender-key warm mark. No code, config, or infrastructure changes.

Re-trigger cubic</sub>

[greptile-apps]

Greptile Summary

This PR adds two <Note> blocks to advanced/signal-protocol.mdx documenting whatsapp-rust#999: the group sender-key warm mark (update_sender_key_devices) now excludes the account's own companion devices, mirroring WhatsApp Web's !isMeDevice guard and closing the permanent-orphan window that persisted after #996.

• Incremental targeting section gains a short forward-reference note explaining that own devices are never entered into the has_key=true bucket and will always receive a fresh SKDM, with a link to the rationale in the fan-out section.
• Parallelized group encrypt fan-out section gains two paragraphs inside the existing <Note>: one narrating the residual window left by #996 (warm-mark coverage of own companions), and one explaining how #999 closes it with a matching exclude_own_devices=true guard and the deliberate trade-off of an extra pairwise SKDM node per send.

Confidence Score: 5/5

Safe to merge — documentation-only change with no code modifications.

The change is purely additive prose in a single .mdx file. Both new Note blocks are internally consistent, the bidirectional cross-reference anchors resolve to their correct headings, and the technical narrative accurately reflects the #999 implementation as described in the PR.

No files require special attention.

Important Files Changed

Filename	Overview
advanced/signal-protocol.mdx	Documentation-only additions; cross-reference anchors resolve correctly, bidirectional links are consistent, and the technical narrative accurately describes the #999 fix and its trade-offs.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant S as Sender
    participant WM as Warm Mark (update_sender_key_devices)
    participant FM as Forget Mark (mark_forget_sender_key)
    participant OD as Own Companion
    participant EX as External Member

    Note over S,EX: Group send — post-ACK warm mark (#999)
    S->>WM: "called with exclude_own_devices=true"
    WM-->>OD: "skipped (never marked has_key=true)"
    WM->>EX: "marked has_key=true"

    Note over S,EX: Retry receipt arrives
    S->>FM: "called with exclude_own_devices=true"
    FM-->>OD: skipped (no-op, but also never warm — no orphan)
    FM->>EX: "marked has_key=false — will re-receive SKDM"

    Note over OD: Own companion always re-included by filter_skdm_targets on next send

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant S as Sender
    participant WM as Warm Mark (update_sender_key_devices)
    participant FM as Forget Mark (mark_forget_sender_key)
    participant OD as Own Companion
    participant EX as External Member

    Note over S,EX: Group send — post-ACK warm mark (#999)
    S->>WM: "called with exclude_own_devices=true"
    WM-->>OD: "skipped (never marked has_key=true)"
    WM->>EX: "marked has_key=true"

    Note over S,EX: Retry receipt arrives
    S->>FM: "called with exclude_own_devices=true"
    FM-->>OD: skipped (no-op, but also never warm — no orphan)
    FM->>EX: "marked has_key=false — will re-receive SKDM"

    Note over OD: Own companion always re-included by filter_skdm_targets on next send

Loading

_{Reviews (2): Last reviewed commit: "docs(signal-protocol): fix link text to ..." | Re-trigger Greptile}

[cubic-dev-ai]

0 issues found across 1 file (changes from recent commits).

<sub>Auto-approved: Documentation update to signal-protocol guide explaining own-device exclusion from sender-key warm mark.

Re-trigger cubic</sub>