Core System Architecture Part 34 — Mixnet, Loopix, Sphinx, Nym & High-Anonymity Transport Architecture

SIAR — Secure, Local-First, Multi-Transport Communication Platform

Series: Core System Architecture
Part: 34
Status: Architecture specification
Primary language: Rust
Scope: high/full anonymity transport integration alongside SIAR's existing direct, relay, LAN, Wi-Fi, Bluetooth, mesh, and DTN transport systems
Design intent: add strong network-metadata privacy without replacing or weakening SIAR's existing transport, E2EE, local-first, emergency, realtime, or offline capabilities

1. Purpose

SIAR already has multiple transport classes intended for different operating environments:

Direct Internet
QUIC / Iroh
Relay
LAN
Wi-Fi Direct / Wi-Fi Aware
Bluetooth
Local mesh
DTN / store-carry-forward

These transports optimize primarily for:

reachability
latency
bandwidth
reliability
offline operation
local communication
emergency communication

They do not, by themselves, provide strong resistance against network metadata analysis.

A network observer may still infer information such as:

which device is communicating
when communication occurs
how often communication occurs
traffic volume
likely sender/receiver relationships
route endpoints
session timing

even when message contents are protected by end-to-end encryption.

Part 34 introduces an independent High-Anonymity Transport Plane based on mix-network principles and compatible providers such as Nym.

The governing principle is:

SIAR must treat anonymity as an explicit routing/security property, not as a side effect of encryption or relaying.

2. Design Goals

The subsystem MUST support:

strong metadata protection
sender/receiver relationship hiding
mixnet routing
Sphinx-style packet encapsulation
cover traffic
randomized delays
store-and-forward reception
anonymous replies
strict downgrade prevention
battery/bandwidth-aware policy
integration with SIAR E2EE
integration with SIAR multipath routing
integration with SIAR DTN
provider abstraction
Nym integration
future SIAR-native mixnet
privacy-safe diagnostics
testability

3. Non-Goals

Part 34 does not attempt to:

replace SIAR E2EE
replace Iroh/QUIC
replace LAN/Bluetooth/mesh
route realtime video through a high-latency mixnet by default
claim perfect anonymity
invent new cryptography
expose mixnet protocol complexity directly to ordinary users

4. Core Architectural Principle

The high-anonymity system is an additional transport plane:

SIAR Application
      │
      ▼
Application E2EE
      │
      ▼
Routing Policy Engine
      │
      ├── Performance Transport Plane
      │     ├── Iroh / QUIC
      │     ├── Relay
      │     ├── LAN
      │     ├── Wi-Fi Direct
      │     └── Bluetooth
      │
      ├── Delay-Tolerant Plane
      │     └── DTN / Store-Carry-Forward
      │
      └── High-Anonymity Plane
            ├── Nym Provider
            └── SIAR Native Mixnet [future]

5. Encryption Is Not Anonymity

The architecture must preserve a strict distinction:

Application E2EE
    protects message content

Transport encryption
    protects transport sessions

Mixnet anonymity
    protects communication metadata and linkage

Therefore:

E2EE ≠ anonymity
anonymity ≠ E2EE

SIAR should normally use:

E2EE + anonymous transport

for anonymous messaging.

6. Mixnet Concept

A mixnet routes messages through multiple intermediate mix nodes.

Each mix node:

receives packets
cryptographically transforms packets
delays packets
reorders packets
forwards packets

The purpose is to make it difficult for an observer to correlate:

input packet
↔
output packet

7. Loopix Role

Loopix provides a useful architectural model for low-latency anonymous messaging.

Important ideas include:

stratified mix topology
Poisson-distributed delays
cover traffic
loop traffic
provider/mailbox nodes
offline recipient support
fixed-size packetization

SIAR should adopt the design concepts, not blindly copy every protocol detail.

8. Sphinx Role

Sphinx is not itself a complete anonymity network.

Within this architecture it represents the packet construction/routing layer that can provide:

layered routing encryption
per-hop transformation
hidden route information
fixed-size or normalized packet structure
integrity protection
unlinkability between hops

Mixing, delays, topology, cover traffic, and route policies are still required.

9. Nym Role

Nym should be SIAR's first external high-anonymity provider.

Reason:

deployed mixnet
Loopix-derived architecture
Sphinx packet design
existing node infrastructure
existing client/runtime ecosystem
practical route to production experimentation

SIAR must integrate Nym through an abstraction rather than embedding Nym assumptions throughout the codebase.

10. High-Level Architecture

┌─────────────────────────────────────────────────────────┐
│                    SIAR APPLICATION                     │
├─────────────────────────────────────────────────────────┤
│ Identity │ Messaging │ Files │ Groups │ Sync │ Plugins │
├─────────────────────────────────────────────────────────┤
│                  Application E2EE                       │
├─────────────────────────────────────────────────────────┤
│              Routing / Privacy Policy Engine            │
├───────────────┬───────────────────┬─────────────────────┤
│ Realtime      │ Delay-Tolerant    │ High-Anonymity      │
│ Transport     │ Transport         │ Transport           │
├───────────────┼───────────────────┼─────────────────────┤
│ Iroh / QUIC   │ DTN               │ AnonymousTransport  │
│ Relay         │ Store/Forward     │   ├─ NymAdapter     │
│ LAN           │ Opportunistic     │   └─ NativeMixnet   │
│ Wi-Fi Direct  │ Mesh              │      [future]       │
│ Bluetooth     │                   │                     │
└───────────────┴───────────────────┴─────────────────────┘

11. Privacy Routing Modes

Ordinary users should select intent, not protocols.

#![allow(unused)]
fn main() {
pub enum PrivacyRoutingMode {
    Standard,
    Private,
    Anonymous,
    MaximumAnonymity,
}
}

12. Standard Mode

Intent:

lowest practical latency
normal SIAR security
normal transport fallback

Allowed paths:

direct
relay
LAN
Wi-Fi Direct
Bluetooth
DTN

13. Private Mode

Intent:

reduce direct endpoint exposure

Possible rules:

prefer relay
avoid direct peer-IP exposure
restrict opportunistic paths
retain reasonable latency

This is not full anonymity.

14. Anonymous Mode

Intent:

strong network metadata protection

Preferred route:

approved mixnet provider

Fallback policy must be explicit.

15. Maximum Anonymity Mode

Intent:

strict anonymity over availability/latency

Required policies may include:

mixnet-only routing
no direct fallback
no ordinary relay fallback
mandatory packet normalization
cover traffic
metadata-minimizing application behavior
privacy-safe logs
restricted plugins
reduced presence
reduced receipts
no external preview fetch

16. Downgrade Prevention

This is a critical security boundary.

#![allow(unused)]
fn main() {
pub enum AnonymityFallbackPolicy {
    NeverFallback,
    AnonymousPathsOnly,
    AskBeforeDowngrade,
}
}

Maximum-anonymity default:

NeverFallback

17. Forbidden Silent Downgrade

Never:

Nym unavailable
→ silently use direct QUIC

because doing so can reveal metadata the user explicitly asked to protect.

18. Route Failure UX Semantics

Correct:

Anonymous route unavailable.
Message remains queued.

Incorrect:

Connection restored through direct route.

without explicit user approval.

19. Route Requirements

#![allow(unused)]
fn main() {
pub struct RouteRequirements {
    pub anonymity: AnonymityRequirement,
    pub latency: LatencyRequirement,
    pub bandwidth: BandwidthRequirement,
    pub reliability: ReliabilityRequirement,
    pub power: PowerRequirement,
    pub offline: OfflineRequirement,
}
}

20. Anonymity Requirement

#![allow(unused)]
fn main() {
pub enum AnonymityRequirement {
    None,
    HidePeerAddress,
    MixnetPreferred,
    MixnetRequired,
    Maximum,
}
}

21. Transport Capability Model

#![allow(unused)]
fn main() {
pub struct TransportCapabilities {
    pub supports_realtime: bool,
    pub supports_offline_delivery: bool,
    pub supports_anonymous_reply: bool,
    pub hides_sender_network_identity: bool,
    pub hides_receiver_network_identity: bool,
    pub provides_cover_traffic: bool,
    pub fixed_size_packets: bool,
}
}

22. Anonymous Transport Interface

#![allow(unused)]
fn main() {
#[async_trait]
pub trait AnonymousTransport: Send + Sync {
    async fn start(
        &self,
        config: AnonymousTransportConfig,
    ) -> Result<(), AnonymousTransportError>;

    async fn stop(
        &self,
    ) -> Result<(), AnonymousTransportError>;

    async fn send(
        &self,
        request: AnonymousSendRequest,
    ) -> Result<AnonymousDeliveryId, AnonymousTransportError>;

    async fn receive(
        &self,
    ) -> Result<AnonymousEnvelope, AnonymousTransportError>;

    async fn status(
        &self,
    ) -> AnonymousTransportStatus;

    fn capabilities(
        &self,
    ) -> AnonymousCapabilities;
}
}

23. Provider Implementations

Initial:

NymAnonymousTransport
TestAnonymousTransport

Future:

SiarNativeMixnetTransport

24. Provider Registry

#![allow(unused)]
fn main() {
pub trait AnonymousTransportRegistry {
    fn available(
        &self,
    ) -> Vec<AnonymousProviderDescriptor>;

    fn resolve(
        &self,
        provider: AnonymousProviderId,
    ) -> Option<Arc<dyn AnonymousTransport>>;
}
}

25. Provider Independence

Core messaging code must never depend directly on:

Nym SDK types
Nym addresses
Nym packet types
Nym node-list internals

These belong inside:

nym-adapter

26. Workspace Proposal

crates/
├── siar-anonymity-core/
├── siar-anonymity-policy/
├── siar-anonymity-routing/
├── siar-anonymity-mailbox/
├── siar-anonymity-cover/
├── siar-anonymity-packet/
├── siar-anonymity-observability/
├── siar-anonymity-testkit/
├── siar-anonymity-nym/
└── siar-anonymity-native/        # future

27. Layer Boundaries

siar-anonymity-core
    provider-neutral types

siar-anonymity-policy
    anonymity/routing rules

siar-anonymity-routing
    route orchestration

siar-anonymity-mailbox
    anonymous asynchronous receiving

siar-anonymity-cover
    cover-traffic policy

siar-anonymity-packet
    packet framing/normalization abstractions

siar-anonymity-observability
    privacy-safe metrics

siar-anonymity-nym
    Nym-specific implementation

siar-anonymity-testkit
    deterministic tests

28. Envelope Layering

Recommended:

SIAR Message
     │
     ▼
Application E2EE Envelope
     │
     ▼
Anonymous Transport Envelope
     │
     ▼
Mixnet Packetization
     │
     ▼
Sphinx/Provider Packet

29. Application E2EE Remains Authoritative

The mixnet provider must never become responsible for SIAR's end-to-end identity/session security.

30. Anonymous Envelope

#![allow(unused)]
fn main() {
pub struct AnonymousEnvelope {
    pub version: AnonymousEnvelopeVersion,
    pub message_class: AnonymousMessageClass,
    pub payload: Bytes,
    pub expiry: Timestamp,
    pub reply: Option<AnonymousReplyDescriptor>,
}
}

31. Message Classes

#![allow(unused)]
fn main() {
pub enum AnonymousMessageClass {
    Control,
    Text,
    AttachmentChunk,
    Receipt,
    Bootstrap,
    MailboxControl,
}
}

32. Packet Size Normalization

Anonymous messages should be converted into normalized cells/packets.

Purpose:

reduce traffic fingerprinting
hide payload-length variation
make cover traffic less distinguishable

33. Fragmentation

Large application payload:

payload
→ anonymous chunks
→ fixed/normalized packet cells

34. Reassembly

Recipient:

cells
→ authenticated reassembly
→ E2EE envelope

35. Fragment Metadata

Must avoid globally linkable identifiers where possible.

36. Reassembly ID

Use cryptographically random scoped identifier.

37. Fragment Limits

Bound:

max fragments
max total message bytes
max lifetime
max incomplete assemblies

38. Cover Traffic

High-anonymity modes may require cover traffic.

Cover traffic makes traffic patterns less directly correlated with real communication.

39. Cover Traffic Policy

#![allow(unused)]
fn main() {
pub enum CoverTrafficPolicy {
    Disabled,
    Adaptive,
    Standard,
    Maximum,
}
}

40. Cover Traffic Constraints

Cover traffic consumes:

bandwidth
battery
relay/mix capacity

Therefore policy must be explicit and resource-aware.

41. Adaptive Cover Traffic

Could consider:

device power state
metered network
battery level
foreground/background
anonymity mode

without leaking per-message intent.

42. Maximum Anonymity

May override battery/network optimization if user explicitly chooses it.

The user should be informed.

43. Delay Distribution

A Loopix-inspired provider may use randomized delay.

Conceptually:

packet
→ delay sampled from configured distribution
→ next mix hop

44. Delay Must Be Provider-Owned

Core SIAR should express:

privacy/latency requirement

not manually implement provider-specific Poisson parameters.

45. Delay Policy

#![allow(unused)]
fn main() {
pub enum AnonymousLatencyClass {
    InteractiveMessaging,
    Balanced,
    MaximumPrivacy,
}
}

46. No False Realtime Promise

High-anonymity message delivery can take seconds or longer.

UI must communicate this honestly.

47. Mailbox / Store-and-Forward

Anonymous communication must support offline recipients.

Architecture:

Sender
  │
  ▼
Mixnet
  │
  ▼
Anonymous Mailbox / Provider
  │
  ▼
Recipient later retrieves

48. Mailbox Goals

recipient can be offline
provider cannot read payload
mailbox identifier minimizes linkability
bounded retention
authenticated retrieval

49. Mailbox Abstraction

#![allow(unused)]
fn main() {
pub trait AnonymousMailbox {
    async fn deposit(
        &self,
        envelope: AnonymousMailboxEnvelope,
    ) -> Result<MailboxDepositReceipt, MailboxError>;

    async fn fetch(
        &self,
        cursor: Option<MailboxCursor>,
    ) -> Result<MailboxBatch, MailboxError>;

    async fn acknowledge(
        &self,
        ids: &[MailboxItemId],
    ) -> Result<(), MailboxError>;
}
}

50. Mailbox Identity

Do not reuse publicly visible:

AccountId
DeviceId

as mailbox address.

Use anonymity-specific addressing.

51. Mailbox Rotation

Support rotating mailbox/routing identifiers.

52. Multi-Device Mailboxes

Each SIAR device may have separate anonymous receiving identity.

Benefits:

reduced correlation
independent revocation
device-local capability

53. Account-Level Anonymous Fanout

Application layer can fan out encrypted payloads to:

device mailbox A
device mailbox B
device mailbox C

54. Anonymous Replies

A sender may need a reply path without exposing a stable receiver address.

Use provider-compatible anonymous reply mechanisms such as:

reply blocks / SURB-like tokens

55. Reply Descriptor

#![allow(unused)]
fn main() {
pub struct AnonymousReplyDescriptor {
    pub kind: AnonymousReplyKind,
    pub token: SecretBytes,
    pub expires_at: Timestamp,
    pub max_uses: u32,
}
}

56. Reply Token Security

Reply tokens are sensitive.

Do not:

log
sync unnecessarily
expose to plugins
include in diagnostics

57. Single-Use Preferred

Where provider permits:

single-use anonymous reply token

reduces correlation/replay risk.

58. Reply Pool

Clients may maintain a bounded pool of reply blocks for asynchronous responses.

59. Reply Pool Replenishment

Must occur independently enough that it does not trivially correlate with a specific incoming message.

60. Anonymous Contact Bootstrap

SIAR can support anonymous introduction flows.

Potential:

Invitation
→ temporary anonymous address
→ mixnet exchange
→ E2EE identity negotiation
→ optional persistent relationship

61. Bootstrap Privacy

Do not expose:

normal direct endpoint
relay endpoint
device IP

during strict anonymous bootstrap.

62. Identity vs Anonymity

Users may communicate anonymously while still cryptographically authenticating to each other.

These are separate properties.

63. Pseudonymous Mode

Future SIAR may support:

stable pseudonymous application identity
+
anonymous network transport

64. Anonymous Mode

Could instead support:

ephemeral application identity
+
anonymous network transport

depending product feature.

65. Route Policy Engine Integration

Existing multipath engine should become privacy-aware.

Concept:

Route Candidate
+
Route Capabilities
+
Privacy Constraints
+
Performance Constraints
→ Valid Candidate Set

66. Route Filtering

First:

eliminate routes violating hard requirements

Then:

rank remaining routes

67. Hard Constraint Example

MaximumAnonymity

rejects:

DirectInternet
Relay
LAN
Bluetooth

unless they are part of an explicitly approved anonymous overlay.

68. Preference Example

Anonymous

may:

prefer Nym
allow approved alternate anonymous provider

69. Path Scoring

#![allow(unused)]
fn main() {
pub struct RouteScore {
    pub privacy: f32,
    pub latency: f32,
    pub reliability: f32,
    pub bandwidth: f32,
    pub power: f32,
}
}

Hard constraints always precede scoring.

70. Never Average Away Security Requirement

A very fast direct path must never beat a mandatory mixnet requirement.

71. Multipath Interaction

For ordinary mode:

parallel candidate paths possible

For strict anonymity:

only anonymity-compatible paths participate

72. Route Migration

If anonymous route changes between mix providers:

new provider session

must preserve application delivery semantics without exposing identity linkage unnecessarily.

73. Failover

Allowed:

Nym Provider A
→ Nym Provider B

if anonymity policy accepts both.

74. Cross-Class Failover

Not allowed without policy:

Mixnet
→ ordinary relay

75. DTN Integration

DTN and anonymity are complementary.

Potential:

E2EE message
→ anonymous envelope
→ mixnet

or:

E2EE message
→ anonymous-capable DTN carrier

But ordinary DTN relays may leak proximity or route metadata.

76. Anonymous DTN Classification

#![allow(unused)]
fn main() {
pub enum DtnPrivacyClass {
    Ordinary,
    MetadataMinimized,
    AnonymousCompatible,
}
}

77. Maximum Anonymity + DTN

Only use DTN routes explicitly certified as compatible with anonymity guarantees.

78. Bluetooth/LAN Interaction

These can reveal:

physical proximity
local network membership
device radio identifiers

Therefore they should normally be disabled in Maximum Anonymity mode.

79. Nearby Discovery

Strict anonymity profile should disable:

automatic local discovery

unless the user explicitly activates a local-proximity feature.

80. Presence Integration

Presence leaks communication metadata.

Anonymity profile may set:

presence = disabled / coarse

81. Typing Indicators

Maximum anonymity default:

off

82. Read Receipts

Maximum anonymity default:

off

or:

delayed/batched

83. Delivery Receipts

Transport reliability may still require internal ACKs.

They should not automatically become user-visible read receipts.

84. Timestamp Precision

High-anonymity mode may reduce exposed timestamp precision.

85. Link Preview Privacy

Disable external automatic URL fetches in strict anonymity mode.

86. Avatar Privacy

Do not fetch avatars from external origins directly.

Use:

SIAR-encrypted/local data

87. Plugin Restrictions

Plugins with:

NetworkAccess
ReadMessages
ReadContacts

can undermine anonymity.

88. Maximum Anonymity Plugin Policy

Possible:

network-capable plugins suspended
message-reading plugins restricted
external integrations disabled

89. Plugin Capability Gate

#![allow(unused)]
fn main() {
pub enum AnonymityPluginPolicy {
    Normal,
    RestrictNetworkPlugins,
    DisableSensitivePlugins,
}
}

90. Telemetry

Maximum-anonymity mode:

no identifying telemetry

Prefer local-only diagnostics.

91. Logging

Never log:

mix route
full anonymous address
reply block
mailbox secret
packet payload
direct-peer identity correlation

92. Privacy-Safe Metrics

Possible:

anonymous send success
anonymous send latency bucket
provider availability
queue depth
cover traffic bytes

without peer identities.

93. Diagnostics

Normal UX:

Anonymous route connected
Anonymous route unavailable
Messages waiting for anonymous route

94. Developer Diagnostics

Could expose:

provider name
connection state
latency class
cover traffic state
packet queue size

but not route secrets.

95. Do Not Expose Mix Route

Showing every mix hop can undermine operational privacy and is generally unnecessary.

96. Anonymous Transport Status

#![allow(unused)]
fn main() {
pub enum AnonymousTransportStatus {
    Disabled,
    Starting,
    Ready,
    Degraded,
    Unavailable,
    Suspended,
}
}

97. Anonymous Delivery State

#![allow(unused)]
fn main() {
pub enum AnonymousDeliveryState {
    Queued,
    Packetizing,
    Submitted,
    Mixing,
    MailboxDeposited,
    Delivered,
    Failed,
    Expired,
}
}

98. User-Facing Simplification

Display:

Queued
Sending anonymously
Delivered
Waiting for anonymous route

not every internal state.

99. Large Attachments

Mixnets are inefficient for large files.

Recommended architecture:

small attachment
→ mixnet chunks

large attachment
→ privacy-preserving rendezvous/token
→ separate approved private transport

only if anonymity guarantees are preserved.

100. Large File Policy

#![allow(unused)]
fn main() {
pub enum AnonymousAttachmentPolicy {
    MixnetOnly,
    AnonymousRendezvous,
    AskUser,
    DisallowLargeTransfer,
}
}

101. No Silent Large-File Downgrade

Never:

mixnet too slow
→ direct file transfer

without explicit policy/user approval.

102. Attachment Threshold

Configured by:

provider capabilities
network cost
battery
latency

not one hardcoded global value.

103. Realtime Calls

Mixnets are generally not appropriate as the media plane for interactive voice/video.

104. Anonymous Call Signaling

Possible:

call invitation/signaling through mixnet

but media may reveal endpoints unless separately protected.

105. Call Privacy Classes

#![allow(unused)]
fn main() {
pub enum CallPrivacyMode {
    Standard,
    RelayPrivate,
    AnonymousSignaling,
}
}

Do not call the media session "fully anonymous" unless the media path actually satisfies that property.

106. Emergency Mode Interaction

Emergency routing prioritizes:

reachability
latency
survivability

Maximum anonymity may conflict.

107. Emergency Policy

The user should explicitly choose between:

Emergency Reachability
Maximum Anonymity

where these goals conflict.

108. Never Silently Disable Emergency Reachability

If Maximum Anonymity prevents local/Bluetooth routes, explain clearly.

109. Power Management

Mixnets consume extra resources because of:

persistent connectivity
cover traffic
packet processing
mailbox polling

110. Battery Policy

#![allow(unused)]
fn main() {
pub enum AnonymousPowerPolicy {
    Adaptive,
    PreserveBattery,
    MaintainAnonymity,
}
}

111. Maintain Anonymity

Can keep cover traffic despite battery cost if explicitly selected.

112. Battery Saver

If OS battery saver limits background activity:

anonymity transport may degrade

Never silently switch to direct transport.

113. Android Background Constraints

Nym/mixnet runtime must integrate with:

foreground service where justified
background restrictions
Doze
network changes
battery saver

114. Android Process Death

Durable anonymous outbound queue remains in Rust storage.

115. Desktop Runtime

Can run anonymity transport in:

daemon

independently of UI.

116. Queue Durability

Anonymous outgoing messages must be persisted before attempting delivery.

117. Queue Record

#![allow(unused)]
fn main() {
pub struct AnonymousOutboxRecord {
    pub delivery_id: AnonymousDeliveryId,
    pub envelope_ref: EncryptedPayloadRef,
    pub provider: AnonymousProviderId,
    pub policy: AnonymousDeliveryPolicy,
    pub state: AnonymousDeliveryState,
    pub created_at: Timestamp,
    pub expires_at: Timestamp,
}
}

118. Payload Storage

Encrypted at rest.

119. Retry

Mixnet retry semantics must avoid:

duplicate user-visible messages
replay amplification

120. Application Message ID

Deduplication remains application-level.

121. Anonymous Delivery ID

Transport-specific.

Do not equate it with:

MessageId

122. Replay Protection

Use:

authenticated envelope IDs
expiry
dedup store
reply-token use limits

123. Expiry

Anonymous packets/messages need bounded lifetime.

124. Expired Message

User-facing:

Message expired before an anonymous route became available.

125. Clock Considerations

Do not rely solely on exact wall-clock synchronization for security-critical replay prevention.

126. Key Material

Mixnet/provider keys must be separated from:

SIAR identity keys
E2EE ratchet keys
device trust keys
backup keys

127. Key Domains

identity key
device key
session E2EE key
anonymous provider key
mailbox key
reply-token secret

all separate.

128. Key Storage

Use existing secure key-store architecture.

129. Key Rotation

Support:

provider identity rotation
mailbox rotation
reply-token rotation

130. Provider Compromise

A compromised provider should not expose SIAR plaintext or primary identity private keys.

131. Node Discovery

Provider adapter obtains mixnet topology through provider-approved mechanism.

132. Core SIAR Does Not Interpret Nym Blockchain Internals

Keep adapter boundary.

133. Topology Cache

Provider may keep:

signed/validated topology snapshot

according to provider requirements.

134. Stale Topology

May degrade route availability.

Do not silently use untrusted topology.

135. Censorship / Blocking

High-anonymity provider connectivity may be blocked.

Architecture should support:

provider transport adapters
bridges/obfuscation if provider supports
multiple entry mechanisms

without compromising security.

136. Censorship Mode

Future:

#![allow(unused)]
fn main() {
pub enum AnonymousAccessMode {
    Normal,
    RestrictedNetwork,
    Bridge,
}
}

137. Sybil Resistance

If SIAR later builds a native mixnet, node admission and Sybil resistance become major separate architecture topics.

Do not improvise them inside Part 34.

138. Native Mixnet Future

Potential future SIAR-native architecture:

Client
  │
Gateway
  │
Layer 1 Mixes
  │
Layer 2 Mixes
  │
Layer 3 Mixes
  │
Mailbox/Gateway
  │
Recipient

139. Native Mixnet Components

Would require:

directory/topology
node identity
node selection
mix packet format
delays
cover traffic
loop traffic
mailboxes
reply blocks
abuse resistance
node incentives/governance
Sybil resistance
measurement
upgrade protocol

Each deserves its own later specification.

140. Do Not Implement New Cryptography

Use:

well-reviewed established constructions
audited crates
provider libraries

where possible.

141. Rust Safety Boundary

Prefer safe Rust.

Any FFI/native code must be isolated behind narrow wrappers.

142. Dependency Policy

Anonymous transport dependencies need stricter review because compromise can undermine anonymity.

143. Supply Chain

Require:

pinned dependencies
cargo-deny
SBOM
audit
signed releases where available
reproducible-build effort

144. Threat Model

Adversaries may include:

local network observer
ISP
relay observer
mix node operator
malicious mix node
colluding mix nodes
global passive observer
active packet injector
malicious recipient
malicious sender
compromised plugin
compromised provider

145. Global Passive Observer

Maximum-anonymity architecture should be designed with this adversary in mind, while being honest that implementation and operational weaknesses can still leak information.

146. Active Attacker

Must consider:

packet tagging
delay manipulation
replay
dropping
traffic shaping
selective denial

147. Intersection Attacks

Long-term user activity patterns can still reveal information.

Mitigations include:

cover traffic
persistent receive behavior
batching
timing normalization

but cannot guarantee perfect protection.

148. Endpoint Compromise

A mixnet cannot protect anonymity if:

device malware
plugin leakage
OS compromise

reveals user activity.

149. Contact Correlation

Application features themselves can create linkability.

Maximum-anonymity profile must minimize these.

150. Abuse Resistance

Anonymous systems can be abused.

Architecture should support provider/core mechanisms for:

rate limits
resource quotas
mailbox quotas
spam control
invitation capabilities

without requiring global identity exposure.

151. Anonymous Rate Limiting

Prefer:

privacy-preserving tokens
capability tokens
local quotas

rather than identity-based tracking where possible.

152. Spam

Unknown anonymous inbound messages should default to:

requests/quarantine

153. Attachment Spam

Do not auto-download anonymous attachments from unknown senders.

154. Malware Safety

Anonymous transport does not imply trusted content.

Existing file validation/sandbox rules remain.

155. Metadata Budget

Every feature in anonymous mode should declare what metadata it emits.

156. Metadata Classification

#![allow(unused)]
fn main() {
pub enum MetadataExposure {
    NoneExpected,
    LocalOnly,
    ProviderVisible,
    NetworkVisible,
    PeerVisible,
}
}

157. Privacy Review

Any new feature that runs under Maximum Anonymity must be reviewed for:

network fetches
timing
identifiers
telemetry
plugins
background traffic

158. Configuration

Human-readable RON:

(
    mode: MaximumAnonymity,
    provider: "nym",
    fallback: NeverFallback,
    cover_traffic: Maximum,
    power_policy: MaintainAnonymity,
)

159. Secrets Not in RON

Never store:

private keys
mailbox secrets
reply tokens

in plaintext configuration.

160. Runtime Config

#![allow(unused)]
fn main() {
pub struct AnonymousTransportConfig {
    pub provider: AnonymousProviderId,
    pub fallback: AnonymityFallbackPolicy,
    pub cover: CoverTrafficPolicy,
    pub power: AnonymousPowerPolicy,
    pub latency: AnonymousLatencyClass,
}
}

161. Policy Resolution

User Privacy Mode
+
Conversation Policy
+
Enterprise Policy
+
Platform Capability
+
Provider Availability
→ Effective Anonymity Policy

162. Conversation Override

User may choose:

Always use anonymous routing for this conversation

163. Conversation Policy

#![allow(unused)]
fn main() {
pub struct ConversationPrivacyPolicy {
    pub routing_mode: PrivacyRoutingMode,
    pub fallback: AnonymityFallbackPolicy,
}
}

164. Enterprise/Managed Policy

Organization may:

require anonymity
forbid external mixnet providers
restrict provider list

165. Policy Conflict

Security/privacy strongest mandatory constraint wins unless policy explicitly defines otherwise.

166. UI Integration

Settings:

Privacy Routing
    Standard
    Private
    Anonymous
    Maximum Anonymity

167. User Education

Maximum Anonymity explanation:

Routes messages through an anonymity network and may increase delay,
battery use, and bandwidth. SIAR will not fall back to less-private
routes without your permission.

168. Per-Conversation Indicator

Subtle:

Anonymous routing

Do not clutter every message.

169. Route Failure Banner

Anonymous route unavailable
Messages are waiting rather than using a less-private connection.

170. Status Semantics

Never say:

Fully anonymous

as an absolute guarantee.

Prefer:

Maximum Anonymity mode

or:

Anonymous routing enabled

171. Diagnostics Integration

Network diagnostics should add:

Anonymous Transport
Provider
Status
Queued anonymous messages
Cover traffic state

172. Support Bundle Redaction

Exclude:

mailbox address
reply tokens
route hops
provider private keys
peer correlation

173. Search Integration

Local search is safe.

External semantic search/AI integrations should be disabled or separately authorized in Maximum Anonymity mode.

174. Backup Integration

Backup may include:

anonymous settings
provider-neutral mailbox metadata

but should generally not restore stale live anonymous session state blindly.

175. New Device Restore

Create fresh:

anonymous provider identity
mailbox credentials
reply-token pool

where security requires.

176. Device Revocation

Revoking device should also invalidate/rotate its anonymous receiving capabilities when possible.

177. Multi-Device Sync

Do not synchronize live reply tokens between devices unless protocol explicitly requires it.

178. Provider Migration

Architecture must support:

Nym
→ future provider

without changing core MessageId/E2EE state.

179. Migration State

#![allow(unused)]
fn main() {
pub enum AnonymousProviderMigrationState {
    Idle,
    Preparing,
    DualReceive,
    Switching,
    RetiringOld,
    Complete,
    Failed,
}
}

180. Dual Receive

Temporary overlap may be required to avoid lost messages.

Must be bounded to reduce correlation.

181. Provider Health

#![allow(unused)]
fn main() {
pub struct AnonymousProviderHealth {
    pub status: AnonymousTransportStatus,
    pub last_success: Option<Timestamp>,
    pub queue_depth: u32,
    pub estimated_latency_class: AnonymousLatencyClass,
}
}

182. No Peer-Specific Provider Metrics

Avoid telemetry that correlates provider timing with specific contacts.

183. Testing Strategy

Part 34 requires dedicated:

unit
property
integration
simulation
adversarial
performance
privacy
fault-injection

tests.

184. Unit Tests

Test:

policy resolution
fallback rejection
queue lifecycle
expiry
fragment bounds

185. Property Tests

Properties:

MaximumAnonymity never selects direct path
duplicate anonymous packet never duplicates user message
invalid reply token rejected
fragment reassembly bounded

186. Downgrade Test

Mandatory invariant:

anonymous provider unavailable
+
NeverFallback
→
message remains queued

187. Route Selection Tests

Matrix:

Standard + Direct
Private + Relay
Anonymous + Nym
Maximum + Nym
Maximum + Nym unavailable

188. Network Fault Tests

Simulate:

provider unreachable
topology stale
mix path drops
mailbox unavailable
high latency
packet duplication
packet reordering

189. Offline Tests

Recipient offline:

sender submits
mailbox stores
recipient later retrieves
dedup applies

190. Reply Tests

single-use reply
expired reply
replayed reply
pool depletion

191. Cover Traffic Tests

Verify:

policy active
rate bounded
battery policy applied
real/cover path indistinguishable at application boundary

without claiming cryptographic proof from UI tests.

192. Metadata Leak Tests

Use canary values to ensure:

AccountId
DeviceId
peer address
MessageId

do not appear in provider-facing fields unless explicitly required.

193. Logging Leak Tests

Canary secrets must never appear in:

logs
support bundles
crash reports
diagnostics

194. Plugin Leak Tests

Maximum anonymity:

network plugin blocked/restricted

as policy defines.

195. Link Preview Tests

External fetch suppressed.

196. Presence Tests

Maximum mode prevents normal high-frequency presence traffic if configured.

197. Performance Tests

Measure:

send latency
queue throughput
packetization cost
mailbox retrieval
memory
CPU
cover traffic bandwidth
battery impact

198. Android Tests

Measure:

Doze
battery saver
background restriction
process death
network switching

199. Desktop Tests

Measure:

daemon restart
sleep/resume
network switching

200. Provider Adapter Contract Tests

Nym implementation must satisfy provider-neutral test suite.

201. Fake Mixnet

siar-anonymity-testkit should include deterministic simulated mixnet.

202. Simulated Mixnet Features

configurable layers
latency
drops
duplicates
mailbox
reply token
route failure

203. No Real Network Required for Most Tests

Real Nym integration tests should be separate.

204. Integration Test Tiers

Fake Mixnet PR tests
Nym test environment nightly
Production-like release validation

205. Fuzzing

Fuzz:

anonymous envelope parser
fragment parser
reply descriptor parser
provider adapter input

206. Resource Exhaustion

Test:

fragment flood
mailbox flood
reply-token flood
queue flood

207. Backpressure

Anonymous queue must have quotas.

208. Quota Model

#![allow(unused)]
fn main() {
pub struct AnonymousQueueLimits {
    pub max_messages: u32,
    pub max_bytes: u64,
    pub max_incomplete_fragments: u32,
}
}

209. Queue Full

User-facing:

Anonymous send queue is full.

Offer safe management.

210. Do Not Downgrade Because Queue Is Full

Hard rule.

211. Monitoring

Local observability:

provider availability
queue depth
cover bytes
success/failure count
latency buckets

212. SLOs

Anonymous transport needs separate SLOs from realtime transport.

Examples:

availability
submission success
mailbox retrieval
bounded queue persistence

213. No Realtime SLA

Do not evaluate mixnet against voice-call latency standards.

214. Failure Semantics

#![allow(unused)]
fn main() {
pub enum AnonymousTransportError {
    ProviderUnavailable,
    PolicyViolation,
    QueueFull,
    PacketizationFailed,
    MailboxUnavailable,
    ReplyTokenInvalid,
    ReplyTokenExpired,
    TopologyUnavailable,
    Unsupported,
    Internal,
}
}

215. PolicyViolation

Used when operation would require privacy downgrade.

216. Security-Critical Errors

Must fail closed:

invalid topology/authentication
reply token integrity failure
packet authentication failure
policy mismatch

217. Unsupported Feature

Example:

live video unavailable in Maximum Anonymity mode

should be explicit.

218. Feature Capability Query

#![allow(unused)]
fn main() {
pub trait PrivacyCapabilityResolver {
    fn evaluate(
        &self,
        feature: FeatureKind,
        mode: PrivacyRoutingMode,
    ) -> FeaturePrivacyCompatibility;
}
}

219. Compatibility States

#![allow(unused)]
fn main() {
pub enum FeaturePrivacyCompatibility {
    Supported,
    SupportedWithDegradation,
    RequiresDowngrade,
    Unsupported,
}
}

220. User-Controlled Downgrade

If action requires weaker privacy:

This call cannot use Maximum Anonymity.
Switch to Relay-Private for this call?

Explicit choice only.

221. Temporary Downgrade

Should be scoped:

this action
this call
this conversation

not global unless user chooses.

222. Policy Audit Event

Record locally:

privacy mode changed
downgrade approved
provider changed

without sensitive peer metadata where possible.

223. Privacy Event

#![allow(unused)]
fn main() {
pub enum PrivacyRoutingEvent {
    ModeChanged,
    ProviderChanged,
    DowngradeRequested,
    DowngradeApproved,
    DowngradeRejected,
    AnonymousRouteLost,
    AnonymousRouteRestored,
}
}

224. Security Center Integration

Could show:

Privacy routing: Maximum Anonymity
Anonymous provider: Ready
Direct fallback: Disabled

225. First-Run Integration

Do not force mixnet setup on every user.

Offer under:

Privacy
Advanced Privacy

226. Recommended Rollout

Phase 1:

provider abstraction
Nym adapter
anonymous text/control messages
no downgrade
durable queue
basic diagnostics

227. Phase 2

anonymous mailbox
reply tokens/SURBs
multi-device receive
attachment chunking

228. Phase 3

cover traffic controls
strict anonymity profile
plugin/presence suppression
provider migration

229. Phase 4

native SIAR mixnet research

230. Do Not Start With Native Mixnet

Building:

mix-node network
directory
Sybil resistance
node selection
incentives
measurements

is a major standalone project.

Use a provider adapter first.

231. Production Readiness Checklist

Before enabling Anonymous mode:

provider adapter audited
downgrade invariants tested
queue crash-safe
logs redacted
mailbox secrets secure
multi-device semantics defined
battery impact measured
provider failure UX complete

232. Maximum Anonymity Readiness

Stricter:

no direct fallback
metadata features suppressed
plugins restricted
external fetch disabled
support bundle redacted
cover traffic configured
reply/mailbox handling tested

233. Security Review Questions

For every anonymous feature ask:

Can this reveal sender IP?
Can this reveal recipient IP?
Can this correlate AccountId to mailbox?
Can this create timing correlation?
Can this leak through plugins?
Can this fetch external resources directly?
Can this silently downgrade?
Can logs expose route secrets?

234. Architectural Invariants

The following are mandatory:

1. E2EE always remains independent of mixnet.
2. MaximumAnonymity never silently selects non-anonymous paths.
3. Provider-specific types never leak into core messaging.
4. Anonymous addresses are separate from AccountId/DeviceId.
5. Reply tokens are secret and never logged.
6. Mixnet failures do not corrupt application message state.
7. Application MessageId provides user-level deduplication.
8. Anonymous queue is durable before send.
9. Large transfers never silently downgrade.
10. Realtime media is never described as anonymous unless its entire path satisfies the claim.
11. Plugins cannot bypass anonymity policy.
12. Diagnostics never reveal full anonymous route secrets.

235. Recommended Crate API Boundary

siar-messaging
    │
    ▼
siar-routing
    │
    ▼
siar-anonymity-core
    │
    ├── siar-anonymity-policy
    ├── siar-anonymity-mailbox
    ├── siar-anonymity-cover
    └── provider
          └── siar-anonymity-nym

236. Dependency Direction

Never:

siar-messaging
→ nym-sdk

Instead:

siar-messaging
→ anonymous transport trait
→ nym adapter

237. Example Send Flow

User sends message
      │
      ▼
Messaging validates
      │
      ▼
E2EE envelope created
      │
      ▼
Route policy:
MaximumAnonymity
      │
      ▼
Select AnonymousTransport
      │
      ▼
Persist anonymous outbox
      │
      ▼
Packetize / normalize
      │
      ▼
Nym adapter
      │
      ▼
Mixnet
      │
      ▼
Anonymous mailbox / recipient
      │
      ▼
Recipient unwraps transport
      │
      ▼
E2EE decrypt
      │
      ▼
Message committed

238. Example Provider Failure

Message persisted
      │
      ▼
Nym unavailable
      │
      ▼
Policy = NeverFallback
      │
      ▼
Remain queued
      │
      ▼
UI: "Waiting for anonymous route"

No direct route is attempted.

239. Example Anonymous Reply

Alice
  │
  ├─ sends encrypted message
  └─ includes reply capability
          │
          ▼
        Mixnet
          │
          ▼
Bob receives
  │
  └─ uses reply capability
          │
          ▼
        Mixnet
          │
          ▼
Alice

Bob need not learn Alice's network location.

240. Example Strict Metadata Profile

Maximum Anonymity
├── Mixnet required
├── Never fallback
├── Cover traffic enabled
├── Presence off
├── Typing off
├── Read receipts off/delayed
├── External previews off
├── Network plugins restricted
├── Local diagnostics only
└── Anonymous mailbox enabled

241. Configuration Migration

Existing users default:

Standard

Do not silently move current traffic to expensive anonymity mode.

242. User Opt-In

Anonymous modes should be explicit because they change:

latency
battery
bandwidth
feature compatibility

243. Enterprise Defaults

Managed deployments may choose stricter default.

244. Documentation

User documentation must explain:

what anonymity protects
what it does not protect
latency tradeoffs
battery/bandwidth tradeoffs
feature limitations

245. No Absolute Claims

Avoid:

impossible to trace
100% anonymous
untraceable

Use:

designed to reduce metadata linkage
stronger anonymity protection
mixnet routing

246. Future Extensions

Potential later architecture parts:

Anonymous Mailbox & Reply Capability Architecture
Native Loopix-Inspired Mixnet Architecture
Sphinx Packet & Cell Architecture
Cover Traffic & Traffic-Shaping Architecture
Mixnet Directory / Node Selection / Sybil Resistance
Anonymous Attachment & Rendezvous Architecture
Anonymity Threat Model & Formal Privacy Verification
Censorship Resistance / Bridges / Obfuscation

These should build on Part 34 rather than duplicate it.

247. Initial Production Scope

Implement first:

AnonymousTransport trait
Nym provider adapter
PrivacyRoutingMode
AnonymityFallbackPolicy
strict route filtering
durable anonymous outbox
small text/control messaging
provider-neutral status
basic packet-size normalization
privacy-safe diagnostics
no-downgrade tests

Then add:

mailbox
SURB/reply capability integration
multi-device anonymous receiving
cover traffic controls
anonymous attachments
strict metadata profile

248. Definition of Done

Part 34 is complete when:

• high-anonymity transport exists as a separate transport plane
• Mixnet, Loopix, Sphinx, and Nym roles are clearly distinguished
• provider-neutral AnonymousTransport abstraction is defined
• Nym is integrated only through an adapter
• Standard/Private/Anonymous/MaximumAnonymity routing modes exist
• NeverFallback prevents privacy downgrade
• anonymous routes integrate with the multipath policy engine
• E2EE remains independent and mandatory for protected message contents
• normalized/fixed-size packetization concepts are defined
• durable anonymous queue semantics are defined
• anonymous mailboxes/offline receiving are accounted for
• anonymous reply/SURB-style capabilities are accounted for
• metadata-sensitive presence/typing/receipts/previews/plugins are handled by anonymity profile
• Bluetooth/LAN/DTN interactions are explicitly constrained by privacy mode
• large attachment behavior cannot silently downgrade
• realtime media limitations are explicit
• Android battery/background and desktop daemon behavior are defined
• privacy-safe observability and diagnostics are defined
• threat model covers passive, active, colluding, provider, plugin, and endpoint adversaries
• no-new-cryptography rule is explicit
• testkit, provider contract tests, downgrade invariants, leak tests, fuzzing, and fault injection are defined
• production rollout can begin with Nym without forcing SIAR to build its own mixnet

249. Final Architecture

                         SIAR APPLICATION
                               │
                               ▼
                         Application E2EE
                               │
                               ▼
                      Privacy Routing Policy
                               │
      ┌────────────────────────┼────────────────────────┐
      │                        │                        │
Standard Paths             DTN Paths           Anonymous Paths
      │                        │                        │
Iroh / QUIC              Store/Forward        AnonymousTransport
Relay                    Opportunistic               │
LAN                      Mesh                        ├── Nym
Wi-Fi Direct                                         │
Bluetooth                                            └── Native Mixnet
                                                         [future]

Strict anonymity path:

Application Message
      ↓
E2EE
      ↓
Anonymous Envelope
      ↓
Normalized Cells
      ↓
Sphinx / Provider Packetization
      ↓
Mix Layers
      ↓
Anonymous Mailbox / Reply Path
      ↓
Recipient
      ↓
E2EE Decryption

Security invariant:

Maximum Anonymity
+
anonymous provider unavailable
=
WAIT

not

FALL BACK TO DIRECT

250. Final Principle

The high-anonymity architecture should not make every SIAR transport anonymous.

Instead, SIAR should become privacy-policy driven:

realtime when realtime matters
local when local matters
DTN when disconnected
mixnet when anonymity matters

while preserving strict boundaries so that choosing stronger anonymity never silently degrades into an easier but metadata-leaking route.

This creates a practical path from SIAR's existing multi-transport architecture to strong mixnet-based anonymity today through Nym, while leaving room for a future native Loopix/Sphinx-inspired anonymity network without coupling the rest of the platform to any one provider.