# Aca-Py Plug-In Architecture Enhancements
Aca-Py currently has support for plug-ins, to support adding additional protocols and extensions to the admin API. There is desire in the community for more extensive plus-in support, to support modifying or extending Aca-Py functionality or behaviour. Additionally, it has been observed that some fucntionality - which has been added to Aca-Py "core" - may be better served by moving to a plug-in.
An additional desired feature of a more comprehensive plug-in architecture is to simplify the overall structure of Aca-Py, by formalizing how new functionalty and behaviour is implemented.
## Existing Plug-in Support
Existing Aca-Py plug-in support is documented [here](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/GettingStartedAriesDev/PlugIns.md).
## Scope of this Document
This document is focussed on the plug-in *features*, as opposed to the internal design (within Aca-Py) of how plug-ins are loaded and configured.
### Loading Plug-ins
There are currently some issues with plug-in dependencies - for example see [this issue](https://github.com/hyperledger/aries-cloudagent-python/issues/2172).
These *may* be addressed by some of the changes recommended in this doc, however the design should be reviewed. This work is TBD.
## High level - Changes/Guidelines Recommended to Plug-in Support
These changes are mentioned/discussed below, but highlighted here.
1. Remove support for a generic `setup()` function - make all the plug-in features explicit and configurable
- Note - see [this code](https://github.com/Indicio-tech/aries-acapy-cache-redis/blob/main/acapy_cache_redis/v0_1/__init__.py) in the redis cache
3. Extend the existing `definition.py` to include the full plugin configuration, and make this file *mandatory* in each plug-in
4. Don't support backward compatibility for "old" versions of `definition.py` (and don't support plug-ins that exclude this file)
5. Use a configuration vs code approach, and be explicit about each plug-in's capabilities
6. Minimize changes required to "core" Aca-Py code
## Prior Discussions on Improving Aca-Py Plug-in Support
This topic was discussed at the [Feb 21, 2023 Aca-Pug](https://wiki.hyperledger.org/display/ARIES/2023-02-21+Aries+Cloud+Agent+-+Python+Users+Group+Community+Meeting), and the presentation can be found [here](https://docs.google.com/presentation/d/1DoBsDGUEGtodteX57-O8S0TD22XrQFwL8unsals-MaY/edit#slide=id.p).
## Desired Plug-in Features
Existing plug-in support includes:
- Ability to add new protocols
- Ability to add new Admin API endpoints
- Ability to register to be notified for specific events on the Aca-Py event bus
- Ability ot register for Aca-Py startup (after loading plug-ins) and shutdown notifications
Desired/potential plug-in support includes:
- Ability to modify Aca-Py behaviour, possibly by inserting hooks/middlewares into the following processes:
- Admin API calls
- Receipt and send of didcomm messages
- WebHook calls
- Ability to add new resolvers, for new DID types and ledger types
- Ability to add new Aca-Py commands (in addition to "start", "provision" and "upgrade")
- Ability to modify the default class (or add additional classes) for providers in the Aca-Py context
- Examples are new ledger types, wallet storage types, etc
- Ability to add additional transport types (inbound and outbound)
- Ability to customize the Admin server behaviour
- Ability to add new credential types (for use in V2 credential and presentation exchange protocols)
Some of these features (adding classes to context, adding resolvers and transports, etc) are available, but not through explicit configuration. These features are added through the "startup" hook or `setup()` method and handled inconsistently between plugins.
Most features can be implemented independently, so they can be scheduled based on community priorities. Most features (as described below) have minimal impact on Aca-Py architecture.
## Aca-Py Architecture Changes
### Changes to existing plug-in support
The existing plug-in model allows a plug-in to register in 2 ways:
- Aca-Py will check for a `setup()` method (in the `__init__.py` file) and if present will execute it
- Otherwise Aca-Py will check for a `definition.py` to check for protocol version information, and then `message_types.py` (for protocols) and `routes.py` (for extensions to the Admin API)
I propose to *remove* support for the `setup()` method - it allows too much flexibility and increases the possibility that plug-ins will interfere with each other, or modify Aca-Py behaviour in undocumented ways.
I also propose to define a configuration file, that will be included within the plug-in, that will define *all* of the capabilities that the plug-in will support. (Essentially an expanded version of the existing `definition.py`.)
The existing `definition.py`, for example, can include the following:
```
versions = [
{
"major_version": 1,
"minimum_minor_version": 0,
"current_minor_version": 0,
"path": "v1_0",
},
{
"major_version": 2,
"minimum_minor_version": 0,
"current_minor_version": 0,
"path": "v2_0",
},
]
```
### Plug-in definition in `definition.py`
I propose that we introduce a ***breaking change*** that a plug-in *must* include a `definition.py` file and that file ***must*** conform to the new structure.
Proposed structure of the "new" `definition.py` - to support the above requirements - is:
```
# introduce a version to easily differentiate between "new" and "old" plugins
plugin_definition_version = "1.0"
# protocols and all related resources
protocols = [
"<name>": [
{
"protocol_definition_version" = "1.0",
"major_version": 1,
"minimum_minor_version": 0,
"current_minor_version": 0,
"path": "v1_0",
"message_types": "...",
"admin_routes": "...",
"event_notifications": "...",
},
{
# ... additional version(s), if provided
}
]
]
}
# additional admin api's - not related to a protocol
admin_routes = [
"<name>": "...",
"<name>": "...",
]
# additional event listeners - not related to a protocol
event_notifications = [
"<name>": "...",
"<name>": "...",
]
# hooks/middlewares for various features
middleware = {
"admin_api": [
"<name>": "<reference>",
"<name>": "<reference>",
],
"webhook": [
],
"didcomm_inbound": [
],
"didcomm_outbound": [
],
}
# ledger and did resolvers
resolvers = [
TBD ...
]
# aca-py startup commands
commands = [
"<name>" = "...",
]
# transports
transports = {
"inbound": [
"<name>": "package.module",
"<name>": "package.module"
],
"outbound": [
"<name>": "package.module",
"<name>": "package.module"
]
}
contexts = [
{
"type": "instance",
"name": "<name>",
"module": "package.module"
},
{
"type": "provider",
"name": "<name>",
"module": "package.module"
}
]
```
Built-in Aca-Py protocols also use the "old style" `definition.py` - to make it easier to maintain these "protocol-only" bundles in Aca-Py the following `definition.py` will also be supported:
```
protocol_definition_version = "1.0",
versions = [
{
"major_version": 1,
"minimum_minor_version": 0,
"current_minor_version": 0,
"path": "v1_0",
"message_types": "...",
"admin_routes": "...",
"event_notifications": "...",
},
{
"major_version": 2,
"minimum_minor_version": 0,
"current_minor_version": 0,
"path": "v2_0",
"message_types": "...",
"admin_routes": "...",
"event_notifications": "...",
},
]
```
For existing protocols, the `definition.py` will need to be updated to include the `protocol_definition_version` attribute, as well as explicit pointers to the `message_types`, `admin_routes` and `event_notifications` attributes.
### Protocols
The aca-py process for loading new protocols won't change (at least not explicitely due to any changes recommended here), however all aspects of the new protocol must be specified in the `definition.py` configuration:
- `major_version` (required) - protocol major version number
- `current_minor_version` (required) - protocol minor version number
- `minimum_minor_version` (required) - minor version "supported" by this protocol
- `path` (required) - sub-path within the plug-in directory structure containing code for thsi protocol version
- `message_types` (required) - name of the module containing message definitions (currently assumed to be `mesage_types`) - if specified, this module *must* contain attributes:
- `MESSAGE_TYPES` (required)
- `CONTROLLERS` (optional)
- `admin_routes` (optional) - name of the module containing admin routes (currently assumed to be `routes`) - if specified, this module *must* contain method:
- `register()` (required)
- `event_notifications` (optional) - name of the module containing event notification registrations (currently assumed to be `routes`) - if specified, this module *must* contain method:
- `register_events()` (required)
If the "optional" parameters are not specified, it will be assumed the associated feature is not provided in the plug-in (i.e. Aca-Py will not "inspect" the package to see if there is a suitable module available).
### Admin Routes
Specify admin routes that are not associated with a specific protocol. (As above.)
### Event Notifications
Register for event notifications that are not associated with a specific protocol. (As above.)
### Middleware
In general, middlewares are chained together to provide pre- and post-processing for events like: inbound and outbound didcomm messages, admin api calls, and webhook calls. We will add the capability for plug-ins to register middlewares for each of these use cases. middlewares will take a standard set of parameters (may be different for each type of middleware), and then when called, will:
- do any required pre-processing
- call the next middleware
- do any required post-processing of the response
- return the (possibly updated) response
This is similar in concept to [Django middleware](https://docs.djangoproject.com/en/4.1/topics/http/middleware/) or [aiohttp web middleware](https://us-pycon-2019-tutorial.readthedocs.io/aiohttp_middlewares.html).
... and each "middleware" will look something like:
```
class middleware:
def __init__(self, get_response):
self.get_response = get_response
# One-time configuration and initialization.
def __call__(self, context, request):
# Code to be executed for each request before
# the next middleware/target is called.
response = self.get_response(context, request)
# Code to be executed for each request/response after
# the other middleware/target are/is called.
return response
```
#### Admin API Calls
The Aca-Py [Admin Server](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/admin/server.py) already uses [aiohttp web middleware](https://us-pycon-2019-tutorial.readthedocs.io/aiohttp_middlewares.html).
So, to support a plug-in's ability to inject into the Admin API endpoint calls will require:
- the plug-in must define a `@web.middleware` function
- the Admin Server must check for supplied middlewares and include them in the call chain
The Admin Server already includes several middlewares, including security, debug, context setup, etc - the plug-in middlewares will get called *after* the core Admin Server middlewares.
Note that the core middlewares can't be replaced or altered - if it is desired to change this behaviour, then the plug-in should introduce a new startup command with a modified Admin Server.
The plug-in configuration to add an Admin Server middleware is:
```
"admin_api": [
"<name>": "<reference>",
"<name>": "<reference>",
],
```
`"<name>"` is just used to identify the middleware, it should document the purpose of the middleware, such as `"extra_security_middleware"`.
`"<reference>"` should refer to the actual middleware function, in the plug-in's source package. For example `middlewares.extra_security`.
The example middleware for this would be (in `middlewares.py`):
```
@web.middleware
async def extra_security(request: web.BaseRequest, handler: Coroutine):
"""Do some stuff."""
# do some stuff ...
return await handler(request)
```
The middlewares will execute in the order in which they're specified in the configuration file.
#### DidComm Inbound/Outbound Messages
Inbound and Outbound messages are handled by the InboundTransportManager and OutboundTransportManager, respectively.
The Controller creates and binds the In/OutboundTransportManager on Aca-Py startup, and these TransportManagers create and manage the transports.
Inbound and Outbound message handlers are created as follows:
```mermaid
sequenceDiagram
App->>+Conductor: create() on startup
Conductor->>+InboundTransportManager: create()
Conductor->>+OutboundTransportManager: create()
Conductor->>InboundTransportManager: setup()
InboundTransportManager->>+InboundTransport: create()
Conductor->>OutboundTransportManager: setup()
OutboundTransportManager->>+OutboundTransport: create()
Conductor->>Dispatcher: create()
Conductor->>Dispatcher: setup()
Conductor->>InboundTransportManager: start()
InboundTransportManager->>InboundTransport: start()
Conductor->>OutboundTransportManager: start()
OutboundTransportManager->>OutboundTransport: start()
```
Inbound message processing:
```mermaid
sequenceDiagram
Agent->>InboundTransport: inbound_message_handler()
InboundTransport->>InboundTransportManager: create_session()
InboundTransportManager->>InboundSession: create()
InboundTransport->>InboundSession: receive()
InboundSession->>InboundSession: handle_relay_context()
InboundSession->>InboundSession: parse_inbound()
InboundSession->>InboundSession: receive_inbound()
InboundSession->>InboundSession: process_inbound()
Note right of InboundSession: insert middlewares here?
InboundSession->>+Conductor: inbound_message_router()
Conductor->>Dispatcher: dispatch_message()
```
Outbound message processing:
```mermaid
sequenceDiagram
App->>Conductor: outbound_message_router()
Conductor->>Conductor: _outbound_message_router()
Conductor->>Conductor: queue_outbound()
alt if has connection
Conductor->>ConnectionManager: get_connection_targets()
else
Conductor->>OobMessageProcessor: find_oob_target_for_outbound_message()
end
Conductor->>Conductor: _queue_message()
Conductor->>OutboundTransportManager: enqueue_message()
Note right of OutboundTransportManager: insert middlewares here?
OutboundTransportManager->>OutboundTransportManager: get_transport_instance()
alt if transport is external
OutboundTransportManager->>OutboundTransportManager: encode_outbound_message()
OutboundTransportManager->>Transport: handle_message()
else
OutboundTransportManager->>QueuedOutboundMessage: create()
OutboundTransportManager->>OutboundTransportManager: process_queued()
OutboundTransportManager->>Transport: handle_message()
end
```
Detail design is TBD
#### Webhook Calls
The Admin Server listens for webhook notifications on the Event Bus:
```mermaid
sequenceDiagram
Conductor->>AdminServer: start()
AdminServer->>EventBus: subscribe()
```
For any received webhook notifications, it calls the webhook router on the Conductor class:
```mermaid
sequenceDiagram
EventBus->>AdminServer: _on_webhook_event()
AdminServer->>AdminServer: send_webhook()
AdminServer->>Conductor: webhook_router()
Conductor->>OutboundTransportManager: enqueue_webhook()
Note right of OutboundTransportManager: insert middlewares here?
OutboundTransportManager->>OutboundTransportManager: get_running_transport_for_endpoint()
OutboundTransportManager->>QueuedOutboundMessage: create()
OutboundTransportManager->>OutboundTransportManager: process_queued()
OutboundTransportManager->>Transport: handle_message()
```
Detail design is TBD, but webhooks are a special case of outbound messages.
A related question is whether webhooks should be dependant on the AdminServer. Aca-Py can run "headless" if no Admin API is required, however in that scenario webhooks would break. We should consider moving webhook related functionality to the `Conductor` class.
### Aca-Py Startup/Shutdown
This is currently handled with the [event bus](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/core/event_bus.py) (Note that there doesn't seem to be any docs describing how to use this.
In the [Conductor](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/core/conductor.py) startup code:
```
await self.root_profile.notify(STARTUP_EVENT_TOPIC, {})
```
... and then in shutdown:
```
await self.root_profile.notify(SHUTDOWN_EVENT_TOPIC, {})
```
Plug-ins can register to receive notifications of the above two events, and can perform any arbitrary processing when these events are fired.
Currently the startup events are used to register new maanger classes into the global context.
I suggest we replace the `STARTUP_EVENT_TOPIC` with the following two events:
- `STARTUP_CONFIGURE_EVENT_TOPIC` - perform any initialization tasks (no side effects)
- `STARTUP_INITIALIZE_EVENT_TOPIC` - perform any startup initialization actions (can have side effects)
The `_CONFIGURE_` event would be called first, for all plugins, followed by the `_INITIALIZE_` event.
### DID Resolvers
DID resolvers are currently handled using start-up parameters:
```
--universal-resolver [<universal_resolver_endpoint>]
Enable resolution from a universal resolver. [env var: ACAPY_UNIVERSAL_RESOLVER]
--universal-resolver-regex <did_regex> [<did_regex> ...]
Regex matching DIDs to resolve using the unversal resolver. Multiple can be specified. Defaults to a regex matching all DIDs resolvable by universal resolver instance. [env var:
ACAPY_UNIVERSAL_RESOLVER_REGEX]
--universal-resolver-bearer-token [<universal_resolver_token>]
Bearer token if universal resolver instance requires authentication. [env var: ACAPY_UNIVERSAL_RESOLVER_BEARER_TOKEN]
```
Recommend to move this configuration information to the plug-in configuration (except possibly the bearer token) and deprecate the start-up parameters.
Detail design is TBD
### Ledger Resolvers
Detail design is TBD (depends on support for non-Indy ledgers in Aca-Py).
### Aca-Py Commands
Available Aca-Py commands are defined [here](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/commands/__init__.py) and the python code implementing each command is located in the `aries_cloudagent.command` package.
Providing the ability to add additional commands allows the plug-in to provide capabilities outside of the above definitions (adding protocols, middlewares, etc).
For example, if an Aca-Py implementer wanted to provide a customized version of the Admin server (customized beyond the scope of what the above capabilities describe), they could define a new command `custom_start` and then provide an implementation of that command. This implementation, within its own `execute(argv: Sequence[str] = None):` method, would be free to start Aca-Py using whatever configuration or custom behaviour it desired. At the same time we can be sure that it won't impact behaviour of other plug-ins because it won't run unless explicitely executed.
Detail design is TBD
### Additional Transport Types
Aca-Py already supports the ability to add additional transport types (inbound and outbound). See for example the [Redis plugin](https://github.com/bcgov/aries-acapy-plugin-redis-events).
Note to look at the transports defined in the [Kafka plugin](https://github.com/sicpa-dlab/aries-acapy-plugin-kafka-events).
Transports (as configured using the `--inbound-transport` and `--outbound-transport` parameters) refer directly to python classes that implement the transports - either a fully qualified name, or a "built-in" transport in the `transports` module. The Inbound and Outbound transport managers each implement code like the following:
```
if "." in config.module:
package, module = config.module.split(".", 1)
else:
package = MODULE_BASE_PATH
module = config.module
imported_class = ClassLoader.load_subclass_of(
BaseInboundTransport, module, package
)
```
... where the `config.module` is supplied from the input parameter (e.g. `http` or `redis_queue.v1_0.inbound`) and the `MODULE_BASE_PATH` is the module for built-ins like `http`.
The recommendation is to provide a mapping in the plug-in's `deployment.py` file, like the following:
```
# transports
transports = {
"inbound": [
"<name>": "package.module",
"<name>": "package.module"
],
"outbound": [
"<name>": "package.module",
"<name>": "package.module"
]
}
```
The provided `"<name>"` is what will be used in the `--inbound-transport` and `--outbound-transport` parameters, and the `"package.module"` will refer to the fully-qualified name for the Transport class.
The Inbound and Outbound TransportManager classes will be pre-configured with something like:
```
MODULE_BASE_PATH = "aries_cloudagent.transport.inbound"
BUILTIN_TRANSPORTS = {
"http": f"{MODULE_BASE_PATH}.http",
"ws": f"{MODULE_BASE_PATH}.ws"
}
```
... allowing us to remove the heuristic logic (determining what class to load for a given transport) and also removing direct package/module references in the Aca-Py parameters.
### Additional Context Classes
Currently Context classes are injected during the "startup" event handling (see previous section). (See [this issue](https://github.com/hyperledger/aries-cloudagent-python/issues/2172).)
For example (this is for the Multitenant Manager Provider Plugin):
```
async def on_startup(profile: Profile, event: Event):
_config = get_config(profile.settings)
profile.context.injector.bind_instance(MultitenantProviderConfig, _config)
profile.context.injector.bind_provider(
BaseMultitenantManager, CustomMultitenantManagerProvider(profile)
)
# the AdminServer was created with the old one injected
# replace it...
srv = profile.context.inject(BaseAdminServer)
srv.multitenant_manager = profile.context.inject(BaseMultitenantManager)
```
It is recommended to make the following changes:
- Remove the dependency on the AdminServer (sinilar to the issue with WebHooks)
- Use configuration to define the additional context classes (similar to the approach recommended for new transports)
For example:
```
contexts = [
{
"type": "instance",
"name": "<name>",
"module": "package.module"
},
{
"type": "provider",
"name": "<name>",
"module": "package.module"
}
]
```
### Other (Potential) Plug-in Capabilities
- Ability to customize the Admin server behaviour
- Need some more specific requirements on this one - if we build the capability to add Aca-Py startup commands, then the new startup command can define any arbitrary funcitonality. We may need to do some refactoring of the Aca-Py classes (such as the AdminServer) to facilitate this.
- Ability to add new credential types (for use in V2 credential and presentation exchange protocols)
- TBD analysis and design is required
# Aca-Py Issues to support Plug-in Upgrades
The following issues will be created. The first one will establish the new `definition.py` format, and then subsequent issues can be completed in any order.
In general:
- when adding new features, add a "deprecated" message but leave "legacy" support in place
- once all new features are implemented, set a date for plug-ins to comply before removing "legacy" support
None of these tickets address packaging the plug-ins, but in general plug-ins should support intallation via pip and poetry (for maximum flexibility).
## Tickets
1. Add Support for New `definition.py` Format
- check for a `plugin_definition_version` or `protocol_definition_version` attribute
- display a "deprecated" message if this attribute is not found (or if there is no `definition.py` file available) however accept for now and leave existing processing as is
- add support for explicit routes, message_types and subscriptions
- update all the existing definition.py's in the aca-py repo:
- the following need to be updated:
aries_cloudagent/protocols/actionmenu/definition.py
aries_cloudagent/protocols/basicmessage/definition.py
aries_cloudagent/protocols/connections/definition.py
aries_cloudagent/protocols/coordinate_mediation/definition.py
aries_cloudagent/protocols/didexchange/definition.py
aries_cloudagent/protocols/discovery/definition.py
aries_cloudagent/protocols/endorse_transaction/definition.py
aries_cloudagent/protocols/introduction/definition.py
aries_cloudagent/protocols/issue_credential/definition.py
aries_cloudagent/protocols/notification/definition.py
aries_cloudagent/protocols/out_of_band/definition.py
aries_cloudagent/protocols/present_proof/definition.py
aries_cloudagent/protocols/problem_report/definition.py
aries_cloudagent/protocols/revocation_notification/definition.py
aries_cloudagent/protocols/routing/definition.py
aries_cloudagent/protocols/trustping/definition.py
- the following need new `definition.py` files:
aries_cloudagent/holder
aries_cloudagent/ledger
aries_cloudagent/messaging/credential_definitions
aries_cloudagent/messaging/schemas
aries_cloudagent/messaging/jsonld
aries_cloudagent/protocols/credentials
aries_cloudagent/protocols/presentations
aries_cloudagent/revocation
aries_cloudagent/resolver
aries_cloudagent/wallet
aries_cloudagent/multitenant/admin
2. Remove Dependency on Admin Server
- remove dependencies on webhooks, event bus
- Webhooks are handled using events - a "webhook notifier" will post an event to the EventBus, and the AdminServer sets up listeners for appropriate events and then converts them to web hooks
- The subscriptions are added in the `start()` method
- There are 2 methods - `_on_webhook_event()` and `_on_record_event()` - that generate webhooks, and the `send_webhook()` method that actually sends the webhook
- This dispatches to the `webhook_router()` method, which is actually a method on the `Conductor`
- If the AdminServer is disabled it will break webhook functionality
- suggest to move webhook logic to the Conductor
- should be able to run aca-py with no admin server with no loss of functionality
- test that webhooks continue to work (although the remaining webhook functionality should work, there are no other AdminServer dependencies that I could find)
- add an option to disable the swagger interface?
- this was requested recently in Discord
3. Additional Aca-py Application Lifecycle Notifications
- add more more granular events on startup
- possible additional events include:
- ledger configured
- transports loaded and configured
- admin server configured
- transports started
- admin server started
- wallet created/initialized
- pre-startup (but make it specific to plug-in configuration)
- post-startup (plug-in initialization, after *all* plug-ins are configured)
- "startup" exists - deprecate the existing startup notification
- add a non-event-based callback "on loaded" for each individual plug-in
- plug-in could do a "post-load-validation"
- investigate using a "lifecycle" interface for plugins to implement
- if the plug-in implemented a "standard" interface, it would ensure a standardized approach for plug-ins to respond to these events
- deprecate use of the implicit "subscription" function
4. Support Configurable Context Classes
- add support for the `definition.py` `contexts` attribute
- standardize the constructors for context classes - providers, etc
- classes provided by plug-ins will need to confirm to standards
- add a deprecation warning message to existing `setup()` support
5. Support Configurable Middlewares (could be up to 4 tickets)
- add support for the `definition.py` `middleware` attribute:
```
# hooks/middlewares for various features
middleware = {
"admin_api": [
"<name>": "<reference>",
"<name>": "<reference>",
],
"webhook": [
],
"didcomm_inbound": [
],
"didcomm_outbound": [
],
}
```
- for each middleware type:
- define the "callback" standard (needs `init()` and `callback()` methods)
- modify plug-in loading to fetch this information into configuration
- for each middleware type, determine where to include (see above design docs) and modify to include the middleware call stack
- investigate how to determine the call "order" (are there dependencies where one needs to be called before another?) (this may be plug-in loading order vs middleware call order, to be determined)
6. Support Configurable Resolvers (DID and ledger)
- add support for the `definition.py` `resolvers` attribute:
```
# ledger and did resolvers
resolvers = [
TBD ...
]
```
- design is TBD
7. Support Configurable Transports
- add support for the `definition.py` `transports` attribute:
```
# transports
transports = {
"inbound": [
"<name>": "package.module",
"<name>": "package.module"
],
"outbound": [
"<name>": "package.module",
"<name>": "package.module"
]
}
```
- as described in the above design
- inboud/outbound transport parameters shouldn't refer directly to the implementing package/module
8. Add Support for Aca-Py Commands
- add support for the `definition.py` `commands` attribute:
```
# aca-py startup commands
commands = [
"<name>" = "...",
]
```
- design is TBD
9. Investigate/Improve Context Management
- See [this issue](https://github.com/hyperledger/aries-cloudagent-python/issues/2172)
```
Also, the way the injection_context and injector works seems to be super heavy? it/they call copy thousands of times (i guess for every call to context.inject(Class)?) My log file was mostly just start_scope and copy.
```
10. Remove deprecation warnings and support for "legacy" plug-ins
- obvs depends on all the above work being completed
Google Drive
Gist
Clipboard
Sign in with Wallet
