1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
//! [`PoolEvent`] / [`PoolRemovalReason`] — the topology/churn feed, byte-compatible with
//! `dig_gossip::PoolEvent` (SPEC.md §5.4, §7.2).
//!
//! # Why this shape is mirrored, not imported
//!
//! SPEC §5.4/§11 originally required `on_pool_event` to consume `dig_gossip::PoolEvent` **verbatim**.
//! In practice `dig-gossip` pulls the entire chia-protocol / consensus / TLS stack into what is a
//! pure decision layer, and its published git tip does not currently compile as a dependency (it
//! lags the upstream `chia-*` crate versions it references). Taking that dependency would both bloat
//! and *break* this crate's build — contradicting the SPEC's own dependency-minimalism principle
//! (§1, §11) and the `dig-dht` / `dig-pex` precedent, which deliberately avoid `dig-gossip` for
//! exactly this reason.
//!
//! This crate therefore mirrors the churn-event shape locally — **byte-identical** field names and
//! variants, over the SAME re-used [`dig_nat::PeerId`] — exactly as `dig-pex` mirrors the L7 address
//! shape "rather than pulling those crates in." The host adapter (`dig-node`) converts a
//! `dig_gossip::PoolEvent` into this type with a trivial 1:1 field map. Because the shapes are
//! identical, the contract is preserved; the SPEC records this deviation (§5.4, §7.2, §11, SEL-01).
//!
//! When `dig-gossip` is published to crates.io with a compiling tip, this module MAY be replaced by a
//! direct re-export without changing any field name or variant — the shapes are the same.
use SocketAddr;
use PeerId;
/// A churn event as the connected pool gains or loses a peer — byte-compatible with
/// `dig_gossip::PoolEvent`.
///
/// The host subscribes to `dig-gossip`'s pool events and forwards each one to the selector via
/// [`crate::PeerSelector::on_pool_event`], which keeps the registry live (SPEC §2.3):
/// - `PeerAdded` **upserts** a registry entry (provenance [`crate::Provenance::Gossip`]), preserving
/// any existing learned quality (a reconnecting peer keeps its history — SPEC §2.3);
/// - `PeerRemoved` marks the peer **disconnected** but **retains** its entry + learned quality so a
/// later reconnect resumes from history (subject to eviction — SPEC §2.5); a `Banned` reason makes
/// the peer ineligible for selection until re-added (SPEC §9.4).
/// Why a peer was removed from the pool — byte-compatible with `dig_gossip::PoolRemovalReason`.