# Mediator integration

## Goal
Easily deploy Aca-py with sub-wallets behind a mediator for scalability.
### note
base wallet will have connection with external mediator, sub wallets will use the mediator endpoint and all messages will enter through a single connection to the base wallet from the mediator.
## Suggested features
* [x] [Admin API, pr #913](https://github.com/hyperledger/aries-cloudagent-python/pull/913) for default mediation
* [x] get default mediator
* [x] set default mediator
* [x] clear default mediator
* [x] Tests
* [x] Mediator feature development in pr [#902](https://github.com/hyperledger/aries-cloudagent-python/pull/902)
* [x] tests for new features
* [x] unit
* [x] using default mediation in connection protocol
* [x] receive/accept connection
* [x] create invitation
* [x] create request
* [x] set default mediator on grant response the life cycle for default mediator setting(create, update, delete)
* [x] set default mediator record
* creates new record, updates if exists
* [x] get default mediation record
* [x] remove default mediator record
* [x] start Aca-py with mediation invitation for default mediator (external mediator design)
* add command line flags for feature
* [x] --mediator-invitation
* [x] --default-mediator-id
* set default-mediation to use a already stored mediation record
* [x] --clear-default-mediation-id
* [ ] base wallet JWT token(might already be implemented?) for mediation configuration (internal mediator)
* [ ] create a sub-wallet with ~~a multi-use invitation from a mediator~~ default `mediator id`/routing record, for using mediation for all connection.
* [ ] automatically establish mediation with base wallet
* [ ] create sub-wallets with default mediation for all connections
* ~~[ ]~~ (future development) ~~configuration for forwarding message as a mediator vs relaying a message as a relay (Might be able to do it automatically )~~.
## Questions
* where should the mediator exist?
* if outside or external
* start an Aca-py instance with a configuration for a mediator
* create multi-use connection invitation
* start another Aca-py instance for multitenancy sub-wallets
* configure base wallet to create sub-wallets with a mediator for all connections
* mediator endpoint will be used for all connections made with sub-wallets. the mediator will send messages for sub wallets over the connection which is to sub wallets through base wallet. the base wallet then forwards messages to sub wallets.messages would flow -> mediator-> base-> sub

* if inside as sub wallet
* start a single Aca-py instance to be used as a multitenancy wallet with sub wallet as a mediator
* create mediator sub wallet and multi-use connection invitation
* configure base wallet to create sub-wallets with a mediator for all connections
* base wallet and mediator could share the same endpoint, but internally messages would flow -> base-> mediator-> base-> sub
* if inside as base wallet
* start a single Aca-py instance ...
* create multi-use connection invitation
* configure base wallet to create sub-wallets with a mediator for all connections
* base wallet and mediator could share the same endpoint, but internally messages would flow -> base/mediator-> base-> sub
* how much configuration should be in Aca-py vs Aca-py controller
using a default mediator could be set and persisted in ether Aca-py or a controller
* bootstrapping a sub-wallet could be done in either Aca-py or a controller. currently, we only need connection and mediation in the bootstrap or post creation of a sub wallet, should we plan on future needed config?
* how do these configurations affect scalability?
* would having configurations in a controller provide better scalability?
* creating new Aca-py base agents on high demand, exporting sub wallets, and importing them into new base agents