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
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
//! Witness infrastructure for split-view defense.
//!
//! This module provides the trait and types for implementing witnesses
//! that help detect split-view attacks on identity KELs.
//!
//! # Split-View Attack
//!
//! A **split-view attack** occurs when a malicious node shows different
//! versions of a Key Event Log (KEL) to different peers. Without witnesses,
//! there's no way to detect this equivocation.
//!
//! ```text
//! Attacker shows:
//! KEL A → Peer 1 (key1 is current)
//! KEL B → Peer 2 (key2 is current)
//!
//! Both peers think they have the "correct" view.
//! ```
//!
//! # Witness Role
//!
//! Witnesses observe identity heads and can report if they've seen
//! a different head for the same identity. This enables detection of
//! equivocation:
//!
//! ```text
//! Peer asks Witness: "What's the head of identity E123?"
//! Witness: "I see commit abc123"
//! Peer: "But my local copy shows def456..."
//! → Split-view detected!
//! ```
//!
//! # Sync vs Async Providers
//!
//! Two witness traits are provided:
//!
//! - [`WitnessProvider`]: Synchronous trait for local/cached operations
//! - [`AsyncWitnessProvider`]: Async trait for network-based operations
//!
//! Use the sync trait when blocking is acceptable (e.g., in-memory cache).
//! Use the async trait for HTTP-based witness servers.
//!
//! # Receipts
//!
//! When a witness accepts an event, it issues a [`Receipt`] - a signed
//! acknowledgment that can be verified later. Receipts enable:
//!
//! - Proof that an event was witnessed
//! - Duplicity detection (witnesses disagree on history)
//! - Threshold-based security (k-of-n witnesses must agree)
//!
//! # Limitations
//!
//! **Witnesses are NOT Byzantine fault tolerant.**
//!
//! - A single witness can be compromised or collude with the attacker
//! - Multiple witnesses (quorum) reduce risk but don't eliminate it
//! - Witnesses must be trusted to some degree
//!
//! For full BFT guarantees, consider transparency logs or blockchain anchoring.
//!
//! # Default: Disabled
//!
//! By default, witness checking is disabled via [`NoOpWitness`]. This is
//! appropriate for:
//! - Private repositories
//! - Single-user setups
//! - Systems with existing consistency mechanisms (e.g., P2P gossip)
//!
//! Enable witness checks for public ecosystems where split-view attacks
//! are a concern.
// Feature-gated modules
// Re-export KERI witness protocol types from auths-keri
pub use KERI_VERSION_PREFIX;
pub use ;
pub use NoOpWitness;
// Collection and duplicity detection
pub use ;
pub use ;
// Receipt verification chokepoint — the only producer of `VerifiedReceipt`.
pub use ;
// Witness server (feature-gated)
pub use ;
pub use ;
pub use WitnessStorage;