fedimint_client/
lib.rs

1//! Client library
2//!
3//! Notably previous [`crate`] became [`fedimint_client_module`] and the
4//! project is gradually moving things, that are irrelevant to the interface
5//! between client and client modules.
6//!
7//! # Client library for fedimintd
8//!
9//! This library provides a client interface to build module clients that can be
10//! plugged together into a fedimint client that exposes a high-level interface
11//! for application authors to integrate with.
12//!
13//! ## Module Clients
14//! Module clients have to at least implement the
15//! [`fedimint_client_module::module::ClientModule`] trait and a factory struct
16//! implementing [`fedimint_client_module::module::init::ClientModuleInit`]. The
17//! `ClientModule` trait defines the module types (tx inputs, outputs, etc.) as
18//! well as the module's [state machines](module::sm::State).
19//!
20//! ### State machines
21//! State machines are spawned when starting operations and drive them
22//! forward in the background. All module state machines are run by a central
23//! [`crate::sm::executor::Executor`]. This means typically starting an
24//! operation shall return instantly.
25//!
26//! For example when doing a deposit the function starting it would immediately
27//! return a deposit address and a [`fedimint_client_module::OperationId`]
28//! (important concept, highly recommended to read the docs) while spawning a
29//! state machine checking the blockchain for incoming bitcoin transactions. The
30//! progress of these state machines can then be *observed* using the operation
31//! id, but no further user interaction is required to drive them forward.
32//!
33//! ### State Machine Contexts
34//! State machines have access to both a [global
35//! context](`DynGlobalClientContext`) as well as to a [module-specific
36//! context](fedimint_client_module::module::ClientModule::context).
37//!
38//! The global context provides access to the federation API and allows to claim
39//! module outputs (and transferring the value into the client's wallet), which
40//! can be used for refunds.
41//!
42//! The client-specific context can be used for other purposes, such as
43//! supplying config to the state transitions or giving access to other APIs
44//! (e.g. LN gateway in case of the lightning module).
45//!
46//! ### Extension traits
47//! The modules themselves can only create inputs and outputs that then have to
48//! be combined into transactions by the user and submitted via
49//! [`Client::finalize_and_submit_transaction`]. To make this easier most module
50//! client implementations contain an extension trait which is implemented for
51//! [`Client`] and allows to create the most typical fedimint transactions with
52//! a single function call.
53//!
54//! To observe the progress each high level operation function should be
55//! accompanied by one returning a stream of high-level operation updates.
56//! Internally that stream queries the state machines belonging to the
57//! operation to determine the high-level operation state.
58//!
59//! ### Primary Modules
60//! Not all modules have the ability to hold money for long. E.g. the lightning
61//! module and its smart contracts are only used to incentivize LN payments, not
62//! to hold money. The mint module on the other hand holds e-cash note and can
63//! thus be used to fund transactions and to absorb change. Module clients with
64//! this ability should implement
65//! [`fedimint_client_module::ClientModule::supports_being_primary`] and related
66//! methods.
67//!
68//! For a example of a client module see [the mint client](https://github.com/fedimint/fedimint/blob/master/modules/fedimint-mint-client/src/lib.rs).
69//!
70//! ## Client
71//! The [`Client`] struct is the main entry point for application authors. It is
72//! constructed using its builder which can be obtained via [`Client::builder`].
73//! The supported module clients have to be chosen at compile time while the
74//! actually available ones will be determined by the config loaded at runtime.
75//!
76//! For a hacky instantiation of a complete client see the [`ng` subcommand of `fedimint-cli`](https://github.com/fedimint/fedimint/blob/55f9d88e17d914b92a7018de677d16e57ed42bf6/fedimint-cli/src/ng.rs#L56-L73).
77
78/// Federation Api announcement handling
79mod api_announcements;
80
81/// Core [`Client`]
82mod client;
83
84/// Client backup
85pub mod backup;
86
87/// Database keys used by the client
88pub mod db;
89
90/// Management of meta fields
91pub mod meta;
92
93pub mod oplog;
94
95pub mod module_init;
96
97pub mod sm;
98pub use client::Client;
99pub use client::builder::ClientBuilder;
100pub use client::handle::{ClientHandle, ClientHandleArc};
101pub use fedimint_client_module as module;
102/// Re-exporting of everything from `fedimint_client_module`
103///
104/// This should be removed when the splitting of [`fedimint_client_module`] is
105/// complete.
106pub use fedimint_client_module::*;