build(deps)!: dig_ecosystem#3152 five-crate cascade — BLOCKED on #2761 (see comment)

[MichaelTaylor3d]

What

The dig_ecosystem#3152 cascade: move dig-node's peer stack onto one line, in ONE atomic commit.

crate	before	after
dig-tls	0.3	0.4.0
dig-nat	0.18	0.20.0
dig-dht	0.11.1	0.12.1
dig-peer	0.11	0.12.0
dig-download	0.19	0.20.4

They gate on each other — dig-download 0.20 requires dig-dht ^0.12 / dig-nat ^0.20 / dig-peer ^0.12 / dig-tls ^0.4 — so all five move together or none do.

DRAFT until the correctness gate returns.

Unblocks the last leg of DIG-Network/dig_ecosystem#1283.

Status

WIP — stub commit pushed first per CLAUDE.md §1.8 so the lane is resumable from remote.

[MichaelTaylor3d]

Measured 2026-08-24: the cascade does NOT line up as scoped. Reporting the shape and stopping, per the brief's own instruction.

Run against main at 7b4caab9 (PR#334 merged). Branch loop/3152-five-crate-cascade, draft PR
#337 — no dependency change is being landed.

First: the five versions are right, and a SIXTH move is required that the brief did not name

All five confirmed from the index (User-Agent: dig-loop): dig-tls 0.4.0, dig-nat 0.20.0,
dig-dht 0.12.1, dig-peer 0.12.0, dig-download 0.20.4.

Two more movers, neither in the brief:

• dig-peer-selector 0.9.0 -> 0.9.2. 0.9.0 requires dig-nat ^0.18; 0.9.2 requires
  dig-nat ^0.20 / dig-dht ^0.12 / dig-peer ^0.12. It is caret-compatible with the declared
  "0.9", so it is a lock-only move — but cargo fetch will NOT take it on its own, and without it
  the lock carries two dig-nat lines while reporting success.
• dig-gossip, which is git-sourced, not crates.io. dig-node-core/Cargo.toml:252,455 pin
  rev 51054a41 (v0.25.0), which declares dig-nat = "0.18" and dig-tls = "0.3". dig-gossip is
  not published at all (index.crates.io/di/g-/dig-gossip returns NoSuchKey), so the index check
  cannot see it. Its main is already on this cascade — 48a14ed2 / v0.30.0,
  "build(deps)!: close the internal chia-line split by adopting dig-tls 0.4 / dig-nat 0.20 (chore(deps): bump dig-gossip -> v0.13.0 (#1517 connect-leg fix) #81)".
  The rev must move with the five or the graph splits.

With all seven applied, cargo tree -i dig-nat, -i dig-tls and -i dig-dht each show exactly one
line. So the peer-stack half resolves cleanly. That is not the problem.

The problem: this is not a peer-stack bump, it is a chia 0.26 -> 0.36 migration of half of dig-node-core

dig-tls 0.4 / dig-nat 0.20 / dig-gossip 0.30 are built against chia-protocol 0.36.1 /
chia-bls 0.36.1, and they pull dig-identity 0.6.0 + dig-message 0.6.1 with them.
dig-node-core declares its own chia-protocol = "0.26" (:92), chia-bls = "0.26"
(:482), dig-message = "0.5" (:151) and dig-identity git tag v0.4.0 (:135).

Applying only the seven moves yields 6 errors in 2 files, all of them new-line values meeting
old-line APIs:

chat.rs:224,269   expected `dig_identity::bls::SecretKey`, found `dig_tls::bls::SecretKey`
chat.rs:460       chia_protocol::bytes::BytesImpl<32>: From<BytesImpl<32>> is not satisfied
peer.rs:411,2389  expected `chia_protocol::bytes::BytesImpl<32>`, found `BytesImpl<32>`
peer.rs:2164      non-exhaustive: `dig_gossip::PoolRemovalReason::Displaced` not covered

Only the last is an ordinary adaptation. The other five say the crate now holds two chia lines.

Measured probe: closing that split forces the chia-peer / chia-query unpin, which is OUT OF SCOPE

I moved chia-protocol, chia-bls, dig-message and dig-identity in dig-node-core, plus
chia-protocol, chia-traits, chia-sha2 and dig-message in the workspace crate
dig-chat-protocol, onto the 0.36 line. The messaging half then compiles and the failures relocate
entirely onto the chia-peer / chia-query / chia-wallet-sdk seams — 17 errors in 6 files:

seams/chia_peer/light_client.rs:66,70,112        chia-peer 0.1.3      (Bytes32, SpendBundle)
seams/chia_peer/coinset_resolver.rs:42,82,97     chia-query =0.5.1    (Bytes32)
seams/dig_peer/store_melted.rs:429,442,452,478   chia-wallet-sdk 0.30 (Bytes32)
lib.rs:2724,3652,3711                            (Bytes32 / &[Bytes32])
peer.rs:498,533  chat.rs:356

dig-node-core has one chia-protocol dependency serving both halves — the peer/messaging
side and the chain/wallet side. There is no version of it that satisfies both while chia-peer 0.1.3,
chia-query =0.5.1 and chia-wallet-sdk 0.30 stay on 0.26. The destinations exist and are all on
0.36.1 — chia-query 0.15.0, chia-wallet-sdk 0.36.0, and chia-peer folded into chia-query — but
adopting them is the unpin this ticket explicitly ruled out and routed to
https://github.com/DIG-Network/dig_ecosystem/issues/2761.

The only way to land #3152 without that is a conversion shim between two chia-protocol lines at
those seams, which is the byte-drift class CLAUDE.md §4.1 forbids outright.

The public-signature check: yes, and from two lines

Asked behaviourally, not against a crate-name list. chia_protocol::Bytes32 reaches
dig-node-core's public surface at chat.rs:51 (SenderKeyResolver), chat.rs:179
(node_sender_did, which also takes a chia_bls::SecretKey), peer.rs:521
(genesis_challenge_from_env), seams/content/content_serve.rs:169 (derive_retrieval_key),
seams/dig_peer/module_anchor.rs:121,130, and seams/dig_peer/store_melted.rs:186,195. Post-cascade
those are reachable from two chia-protocol lines (0.36.1 via dig-tls/dig-nat/dig-gossip/dig-message,
0.26 via chia-peer/chia-query/chia-wallet-sdk). That is precisely the internally-split shape that
shipped twice on 2026-08-22, and it is why the compiler is right to refuse.

What this changes about the sequencing

The manifest comments at dig-node-core/Cargo.toml:112-122 and dig-wallet/Cargo.toml:83-92 — which
I verified survived PR#334's merge intact, unchanged, no edit needed — call #3152 "the chia-0.36
cascade" and say the chia-peer unpin is blocked on it. Measured, the dependency runs the other
way: the peer-stack uplift cannot land until the chain-side crates move to chia 0.36. So

#2761 is not downstream of #3152. It is a prerequisite of it.

This inverts the plan recorded on this ticket, and it means #3152 cannot currently unblock
https://github.com/DIG-Network/dig_ecosystem/issues/1283's last leg — #2761 has to go first.

Recommended order, all inside one dig-node lane since it is one repo:

1. #2761 — chia-peer 0.1 -> chia-query 0.15, chia-query =0.5.1 -> 0.15,
   chia-wallet-sdk 0.30 -> 0.36, and dig-wallet's chia-query 0.6.2 collapsed onto the same
   line (which also discharges #2227's two-chia-query-lines note). 17 error sites, 6 files, bounded.
2. #3152 — then the seven moves above, plus chia-protocol/chia-bls/dig-message/dig-identity
   in dig-node-core and chia-protocol/chia-traits/chia-sha2/dig-message in
   dig-chat-protocol, plus the one-variant PoolRemovalReason::Displaced match arm.

Nothing was landed. PR#337 stays draft and carries only its stub commit; it can be reused when #2761
clears, or closed.

Also worth recording

• cargo tree -d is confirmed useless as a gate here: chia-bls alone resolves to six lines
  (0.22.0, 0.26.0, 0.28.2, 0.36.1, 0.42.1, 0.45.0) via clvmr, chialisp and clvm_tools_rs, on the
  unmodified tree. Any correct implementation fails it.
• bootstrap.rs:209's local dial_candidates was left alone, as decided.

[MichaelTaylor3d]

Closing — the cascade does not line up as scoped, and the finding is recorded where it will be read: https://github.com/DIG-Network/dig_ecosystem/issues/3152#issuecomment-5394175207

#2761 is a prerequisite of #3152, not downstream of it. dig-node-core has one chia-protocol dep serving both halves, and no version satisfies both while chia-peer / chia-query / chia-wallet-sdk stay on 0.26. The only alternative was a two-line conversion shim — the §4.1 byte-drift class, and never the fix.

This PR carried a stub commit only; nothing was built on the wrong shape. Reopening a branch here after #2761 lands is cheaper than keeping a stale draft that reads like work in progress.