# Client Software Architecture Overview
This document describes the decomposition of a hypothetical Wildland client into many functional blocks. It is expected that many of these blocks can be designed, implemented and tested largely indepedently. Morover, some components, such as ACB or UI frontends, might exist in multiple implementations, each providing a different feature set or tradeoff between performance, security and privacy.
Other implementations (i.e. other than the reference one) might be written and they might not follow the decomposition structure presented here. However, we refer to these modules in other parts of the documentation in order to break down this complexity into managable pieces.
The most important parts of the architecture are discussed below.
# CoreX module
It's responsible for:
- resolving Wildland addresses
- container metadata manipulations
- container storage management
- encryption and decryption of container metadata and storages
- handling of the data encryption symmetric key
No notion of a "user", "device", "sharing"!
# Admin Manager module
It's responsible for setting up ACLs in response to:
- FS/Forest namespace -> container mappings
- Forest sharing
- adding new Forest owners
- adding new devices by Forest owner
- Forest access revoking (e.g. iterating over all storages in the Forest and re-generating storage access credentials)
- maintaining user - devices - keys relationships
It understands the notion of a "user", "device", "sharing logic". Different usage scenarios may have different implementations of the Admin Manager module, each tailored to the specific use case.
# Data/FS provider (DFS)
It's responsible for:
- moving data from/to actual storages (S3, WebDAV, etc.)
- exposing mounted Forests to the user, e.g. via FUSE or local sync
- encryption of the data (key obtained from CoreX)
More information on DFS is provided in a dedicated document.