Aries in action, overview through video.
To understand Aries mediator, first we must understand Aries.
This 6 min video shows an overview of what Aries along with Indie and Ursa enables.
And this is a look behind the screen at internals of what Aries communication protocol looks like.
As you can see above the Aries protocol is pretty symmetric. The Aries agents talk as equals. There's no concept of server - client as in protocols like HTTP(S).
p2p symmetry on an asymmetric capability internet
With Aries anybody can talk to anybody directly, and either can initiate, provided they find a suitable medium to exchange messages. In networking parlance this is p2p (peer to peer). Aries agents being the peers.
That's cool and all. But in today's Internet we still have to face the mobile dilemma: Mobile devices, like Alice's smartphone don't generally have a static address on the Internet. They roam networks, popping up in cyberspace whenever and wherever their holders connect from. They are not consistently online in time, nor having stable location. Unlike institutional servers / cloud agents that can run 24/7 at a fixed address.
So how does an institutional Aries peer, say Poorav University (P), send a credential invite to Alice (A)?
-
Where should P send them?
-
Also, when exactly should P send them?
Even in a future with with widespread ipv6 deployment and reliable persistent addressing for all, there would still be a problem of when to send them. Because mobile devices are generally asleep (when not in active use), waking up from low power state only interstitially to fetch messages/notifications from preconfigured servers.
welcome mediators
These are the problems that the mediator service tackles.
If the mobile Aries agent can't be reliably, predictably available in time and space, it can delegate the availability property to someone else. In the real physical world, there already exist concepts that solves the problem of changing addresses. For example, a P.O box, or post office box (not to be confused with postbox) is an address that persons can subscribe to at a post office. Where they can have messages for themselves sent. And then collect them later, either regularly or whenever it suits them.
The mediator service (M) does a similar job. Aries agents like Alice's can subscribe to an address with the mediator service. And make it known to parties willing to communicate with Alice. The parties then deliver messages to the mediator address. Where they are reliably received and stored by the service, to be later fetched by Alice agent when it comes online.
Note: It's not necessarily a proxy, since Alice's agent need not reply with messages destined for P through M. It can reply directly to P's address (Since P may be reliably available) or to P's mediator services. 🤷
privacy and confidentiality considerations
Note that since all messages between A and P are encrypted, the mediator service in essence deals with only sealed envelopes. And is not a major concern in regards to confidentiality of message contents. There may be concerns of metadata privacy however (who is sending invites to Alice, how often Alice gets invites and when, etc). So Alice must choose a trustable mediator service provider.
working on this : yours truly
P.S: My task as per this mentorship is to develop an implementation of the mediator service in Rust lang, using the aries vcx library as base. It is going to be open source and presumably available under Apache Licence.