Expand description
Extenable module sysystem Fedimint supports modules to allow extending it’s functionality. Some of the standard functionality is implemented in form of modules as well.
The top level server-side types are:
Top level client-side types are:
ClientModuleInit
(infedimint_client
)ClientModule
(infedimint_client
)
Re-exports§
pub use serde_json;
Modules§
- version 🔒Fedimint consensus and API versioning.
Macros§
- Example
Structs§
- Authentication uses the hashed user password in PHC format
- Definition of an API endpoint defined by a module
M
. - State made available to all API endpoints for handling a request
- All requests from client to server contain these fields
- Api version supported by a core server or a client/server module at a given
ModuleConsensusVersion
. - Consensus version of a core server
- Consensus version of a specific module instance
- Multiple, disjoint, minimum required or maximum supported,
ApiVersion
s. - A handle passed to
ServerModuleInit::distributed_gen
- Creates a struct that can be used to make our module-decodable structs interact with
serde
-based APIs (AlephBFT, jsonrpsee). It creates a wrapper that holds the data as serialized - A summary of server API versions for core and all registered modules.
- A summary of server database versions for all registered modules.
- Information about the amount represented by an input or output.
Constants§
- Globally declared core consensus version
Statics§
- REQ_ID 🔒Global request ID used for logging
Traits§
- Logic and constant common between server side and client side modules
- Operations common to Server and Client side module gen dyn newtypes
- Interface for Module Generation
- Module associated types required by both client and server
- Trait implemented by every
*ModuleInit
(server or client side) - Module Generation trait with associated types