swcurran
commented
1 month ago Here is a rough overview off the top of my head.
- At first start up a mobile wallet is pre-configured to connects via DIDComm to its mediator and then asks (in a message) the mediator to mediate for the wallet. The mediator says “sure!”.
- The mobile wallet could also be enabled to choose its own mediator — and could even use multiple mediators.
- The connection is established between the wallet and the mediator to support websockets.
- As a mobile wallet is establishing a connection to another agent, it sends a message to the mediator that says I need a new connection mediated. The mediator creates a key pair for the connection, records the relationship between the new public key and the connection it has with the mobile wallet. It then sends back to the mobile wallet the public key to use for the connection.
- The mobile wallet then puts into the DIDComm service entry in the peer DID that it sends to the other side of the connection:
- the public key the mobile wallet knows to be used for encrypting the DIDComm messages to the wallet.
- the public key the mediator supplied to be used to encrypt a wrapper around the DIDComm message.
- the endpoint of the mediator.
- When the mediator receives a message it determines the public key used to encrypt it, decrypts it, and then uses the public key to look up what connection to forward the message to. If it is using websockets, it determines if it has an active websocket for the connection, and if so, sends the message along. If not, it queues the message for sending when the mobile wallet connections back in.
I think it is that last bit you are looking for. The overall process is covered in RFC 0046 Mediators and Relays, RFC 0211 Mediator Coordination and RFC 0685 Pickup Protocol v2.
The painful part as that is described is that the mediator can not horizontally scale (many instances) because the websockets have to remain connected to the same instance of ACA-Py that is the mediator. There is a component Aries SocketDock that addresses this — allowing ACA-Py to scale, but AFAIK, no one has published an open source DIDComm Mediator that has SocketDock support. For now, we just throw hardware at the mediator. Not ideal, but…
Hope that helps.
In ACA-Py, when a message needs to be forwarded to a mobile wallet, how the mediator determines which WebSocket connection (session) to use? How websocket connections are managed? Any insight will be very much appreciated!