PQs and Caches for ACA-Py and Mediators

Mediators

Design 1: No Relay/Deliverer, No Controller

A "no controller deployment" is viable by either setting the --auto flags, or by extending the mediation negotiation plugin to include business logic, so that there is no need for a controller.

        

    

    

      Image Not Showing
      Possible Reasons
      
The image file may be corrupted
The server hosting the image is unavailable
The image path is incorrect
The image format is not supported
      Learn More →
    
  
      

See Overview below for more details about both designs.

Design 2: Combined Relay/Deliverer

        

    

    

      Image Not Showing
      Possible Reasons
      
The image file may be corrupted
The server hosting the image is unavailable
The image path is incorrect
The image format is not supported
      Learn More →
    
  
      

Overview

• The "agents" only send messages destined for wallets.
  • They are received and queued on Redis with a topic based on the recipient wallet.
• Each wallet connects with WS to a mediator instance and when connected, has a session with that mediator endpoint.
  • In establishing a web socket session, the agent sends a DIDComm message to pickup messages.
  • The wallet that establishes the web socket and sends the DIComm message is not known until the DIDComm message from the wallet is processed.
  • If the endpoint is managed from a different component (e.g., a Relay/Deliverer instance) than is processing the DIDComm message (e.g., an ACA-Py/Mediator instance), the two components must coordinate about which recipient is processing the messages for what wallet.
  • Proposal is as follows:
    • Two identifiers are needed, a tag for the web socket session, and a Wallet identifier The wallet identifier is the same identifier the ACA-Py/Mediator (AM) instances will use in queing messages destined to a wallet to Redis.
    • When a Relay/Deliverer (RD) instance receives a message to establish a new web socket session, the RD tags the message with a locally understood session identifier, puts it on the Redis queue, and adds the tag to a list of things on the Redis queue it is tracking.
    • An AM instance retrieves the "new session" message from the Redis queue, noting the tag from the RD, processes the DIDComm message and extracts the wallet ID.
    • The AM queues a message on Redis with the topic being the RD-generated tag and the content being the Wallet ID.
    • When the RD instance sees the message with the tag, it retrieves the message, and adds the Wallet Identifier to the list of things on the Redis queue it is tracking.
    • While the web socket is active, the RD monitors Redis for messages for the wallet identifier and sends them to the wallet using the web socket session.
    • When the web socket is lost, the RD instance stops looking on Redis for the wallet ID messages.
    • If the RD dies, the wallet will establish a new web socket connection, and that RD instance will take over sending messages to that wallet.
• Wallets only retrieve messages from the mediator.
• Exception: When a wallet is negotiating with the mediator, messages are sent from the wallet to the mediator, and from the mediator to the wallet.
  • In such cases, it is likely the business logic is involved to make decisions on the mediation setup – accept the wallet or not, at minimum.
  • Messages from the Wallet should be sent to the mediator, as if it was any other agent.
  • Messages from the Mediator would be sent to the wallet as if sourced from an external agent.

Logic

• On receipt of a message destined for a wallet, the mediator instance checks if it has a WS session with the wallet. If not, it puts the message on the Redis queue.
  • If the mediator is the source of the message, it would process the outbound message to a wallet as if it had already been retrieved from an external agent.
• When connected with wallet(s), an agent polls the Redis queue for messages for wallet(s), and when found, retrieves message from the queue and send the message to the wallet.

Other Issues

• There is no confirmation of a message being received by the wallet, which could lead to messages being lost because of an undetected lost connection.
• The mediator should handle mobile notifications to

ACA-Py

Design 1: Separate Relay and Deliverer Components

Design 2: Combined Relay and Deliverer Component

Overview

Optional Deployment: Controller Shares Relay/Deliverer

To make a cloud native controller scalable, have it use Redis and the Relay / Deliverer.

Webhooks arrive into the Relay, are put into Redis and retrieved from Redis by the Controller instances, who process the requests.

Results of the controller processing that result in requests to the ACA-Py Admin API are put into Redis, where the deliverer picks them up and sends them to ACA-Py.

An optimization would be to have the controller put them in Redis such that ACA-Py picks them up directly, without the deliverer involved. Likewise, the webhooks would go into Redis from ACA-Py where they are picked up by the Controller without the deliverer or relay involvement.