citadel_user 0.14.0 

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
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142

//! # Citadel User Management System
//!
//! A comprehensive user and account management system for the Citadel Protocol, handling both
//! network nodes and client accounts within the VPN architecture. This crate provides
//! the foundational user management layer for the entire Citadel Protocol ecosystem.
//!
//! ## Features
//!
//! * **Account System**:
//!   - Network Accounts: Core network identity
//!   - Client Accounts: Per-connection user accounts
//!
//! * **Backend Support**:
//!   - File System Storage: Persistent local storage
//!   - Redis Database: High-performance caching
//!   - SQL Database: Relational data storage
//!   - In-Memory Storage: Fast temporary storage
//!
//! * **Authentication**:
//!   - Secure Credential Management: Password and key handling
//!   - Google Authentication: OAuth and service account support
//!   - Custom Authentication: Extensible provider system
//!
//! * **External Services**:
//!   - Google Services: Cloud service integration
//!   - Firebase RTDB: Real-time data synchronization
//!   - Service Interface: Common communication layer
//!
//! * **Account Management**:
//!   - Account Creation: Secure account initialization
//!   - Credential Updates: Safe password and key rotation
//!   - State Management: Account lifecycle handling
//!   - Account Recovery: Backup and restore features
//!
//! ## Architecture
//!
//! The system is built on a network-client account structure:
//!
//! ```text
//! Network Account (NAC)
//! └── Client Account (CNAC)
//!     ├── Connection Metadata
//!     ├── Credentials
//!     └── External Services
//! ```
//!
//! ## Security Features
//!
//! * Zero-trust architecture
//! * Post-quantum cryptography support
//! * Secure credential storage
//! * Safe account recovery
//! * Encrypted data transmission
//!
//! ## Important Notes
//!
//! * Multiple ClientAccounts can exist per node
//! * All operations are safe and secure by default
//! * File system operations are feature-gated, enabled by default
//! * External services require appropriate feature flags
//!
//! ## Related Components
//!
//! * [`citadel_crypt`]: Cryptographic operations
//! * [`citadel_wire`]: Network communication
//! * [`citadel_types`]: Common type definitions
//! * [`citadel_pqcrypto`]: Post-quantum cryptography
//!
//! ## Feature Flags
//!
//! * `filesystem`: Enable file system storage
//! * `google-services`: Enable Google service integration
//! * `redis`: Enable Redis database support
//! * `sql`: Enable SQL database support
//!
#![forbid(unsafe_code)]
#![deny(
    trivial_numeric_casts,
    unused_extern_crates,
    unused_import_braces,
    variant_size_differences,
    unused_features,
    unused_results
)]
#![allow(rustdoc::broken_intra_doc_links)]

/// Standard imports for this library
pub mod prelude {
    pub use crate::client_account::*;
    pub use crate::connection_metadata::*;
    pub use crate::hypernode_account::*;
    pub use citadel_crypt::scramble::streaming_crypt_scrambler::MAX_BYTES_PER_GROUP;
}

/// Serde and others
pub mod re_exports {
    #[cfg(all(feature = "filesystem", not(target_family = "wasm")))]
    pub use crate::directory_store::DirectoryStore;
    #[cfg(feature = "google-services")]
    pub use firebase_rtdb::FirebaseRTDB;
    pub use serde::*;
}

/// The general trait for creating account types
pub mod hypernode_account;

/// Each node must necessarily have a NetworkAccount that is invariant to any ClientAccounts.
/// See the description for [client_account] below for more information.
pub mod connection_metadata;

/// Each client within a VPN has a unique ClientAccount. Multiple CAC's are possible per node.
///
/// Structural design notes: In production mode, it is necessary that a [ClientNetworkAccount] be
/// created by virtue of the subroutines within the [NetworkAccount]. In other words, a NAC is not
/// only needed, but also the means for creating a CNAC. NAC -> CNAC. It terms of abstraction, we
/// now ascend a level: Let the node at any point along the network, independent of central server,
/// be called a NAC. A NAC is necessary to connect and create mutually-trusted connections within
/// the WAN (Wide-area network).
///
/// evoc_null(web 3.0) => void && let void alloc finite && set network evoc_null(!VPN)
pub mod client_account;

#[cfg(any(feature = "filesystem", feature = "opfs"))]
/// This provides methods to load all locally-stored files
pub mod account_loader;
/// The server in legacy_citadel_proto requires a means of handling the user database. This module contains the means of achieving this
pub mod account_manager;
/// For authentication
pub mod auth;
/// For handling different I/O operations
pub mod backend;
pub mod credentials;
#[cfg(any(feature = "filesystem", feature = "opfs"))]
/// Environmental constants and subroutines for pre-checking the system
pub mod directory_store;
/// For services
pub mod external_services;
/// For errors
pub mod misc;
/// Contains basic subroutines for serialization
pub mod serialization;
pub mod server_misc_settings;