docs: DACS/SR-4 progress + negotiate-rfq slice plan#947
Conversation
Captures where DACS stands now that the SR-4 substrate is merged: what's done (CCI binding, channel envelope, transcript anchor, L2PS transport, identity invariant), what's not (transport wiring, negotiate-* orchestration, AgreementDocument co-sign, E2E), the L2PS-messaging ↔ SR-4 integration assessment (4 gaps), and the next vertical slice broken into WI-A..E (channel-over-L2PS adapter → negotiate-rfq phase logic → transcript anchor → agreement co-sign → E2E harness). Notes the DACS-3 §8.4 spec dependency. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughA new documentation file ChangesDACS SR-4 Progress Documentation
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Greptile SummaryThis PR adds a DACS/SR-4 progress document and next-slice plan. The main changes are:
Confidence Score: 3/5The document is mergeable, but the next-slice plan leaves several transport and membership integration details underspecified. The changed file is documentation-only and the issues are concentrated in the WI-A adapter plan, where current messaging behavior does not yet match the described DACS channel requirements. docs/dacs-progress.md Reviews (1): Last reviewed commit: "docs: DACS/SR-4 progress + negotiate-rfq..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| - `send(channelMsg)` → serialize envelope → L2PS messaging `send` with a | ||
| `dacs` message type, encrypted under the subnet key. |
There was a problem hiding this comment.
This step says the adapter can send with a dacs transport message type, but the current L2PS messaging send payload only carries to, encrypted, and messageHash, and the server does not persist or forward a message kind. An implementation following this plan can silently lose the DACS discriminator, so receivers still cannot distinguish channel envelopes from normal chat traffic.
| `dacs` message type, encrypted under the subnet key. | ||
| - `onReceive` → deserialize → **reorder buffer** keyed on `sequence` → | ||
| `session.receiveIncoming` in order. | ||
| - Map `channelId` to the subnet `uid` (1 channel = 1 subnet) for routing. |
There was a problem hiding this comment.
Mapping channelId to the subnet uid only chooses the L2PS network. The current messaging transport still requires a single to recipient and routes one message to one peer, while this document describes DACS channels as N-party groups. A multi-party channel can therefore miss members unless WI-A also specifies fanout to every bound channel member or explicitly scopes this slice to two-party channels.
| - `onReceive` → deserialize → **reorder buffer** keyed on `sequence` → | ||
| `session.receiveIncoming` in order. |
There was a problem hiding this comment.
The reorder buffer is keyed only on sequence, but sequences are per channel/session. If one client handles two channels and both receive sequence=1, a sequence-only buffer can mix, drop, or unblock the wrong channel message before calling session.receiveIncoming. The adapter plan should key the buffer by channelId or session plus sequence.
| **DoD:** two clients on one subnet exchange signed `ChannelMessage`s in | ||
| both directions; out-of-order arrivals are buffered and applied in | ||
| sequence; a non-member (no subnet key) cannot read. |
There was a problem hiding this comment.
This DoD only proves that a non-member without the subnet key cannot read messages. The existing L2PS messaging registration proves key ownership and a loaded l2psUid, not DACS channel membership, so a subnet participant that is not bound to the channel can still send DACS-looking encrypted envelopes. WI-A should require rejecting envelopes whose signer is not in the WI-1 channel membership before they reach the session.
2 participants
Status doc for DACS now that the SR-4 substrate is merged.
Done (substrate, merged): CCI membership binding (WI-1), ChannelMessage envelope w/ sequencing + CCI-key signing (WI-2), encrypted transcript anchor (WI-3) — sdks#94; L2PS transport (subnet/messaging/balance/nonce) — node #936/#937/#943/#944/#945; identity invariant (Demos key = CCI key = on-chain party) already aligned.
Not done: transport wiring (SR-4 envelope to L2PS messaging), negotiate-rfq / sealed-envelope orchestration, AgreementDocument co-sign, E2E.
Integration assessment: L2PS messaging and SR-4 are individually solid and share the same ed25519 identity, but currently disjoint. Four gaps to bridge (ordered delivery / channelId routing / dacs message-type / anchor de-dup). Recommendation: keep SR-4 transport-agnostic, wire via a thin adapter.
Next slice: negotiate-rfq end-to-end as WI-A..E.
Dependency: DACS-3 §8.4 spec — referenced by the SR-4 brief but not in our repos; needed from WI-B onward.
Doc only — no code changes.
Summary by CodeRabbit