Please describe your proposed solution.
For many, this is a new concept. So, before delving into the specifics, let's briefly discuss what a DIDComm is. DIDComm v2 is a messaging protocol that facilitates the secure transfer of messages from one wallet (or agent) to another. The specification for DIDComm v2 is about a year old and is rapidly becoming the standard for message encoding in the world of digital identity. Atala PRISM v2 implemented DIDComm in the spring of this year, using the protocol to send Verifiable Credentials from one wallet to another. Interestingly, DIDComm is just a base protocol, and the exchange of credentials is just one of its many potential use cases. Others could include text messaging or even file transfer. We have already implemented several of these protocols, and we will delve into more detail about them later. But first, let's answer the question: what exactly is a mediator?
To simplify it a bit, we can compare a DIDComm Mediator to an email server. To send an email from one client to another, you need at least one email server. For most people, this is a 'free' service (we all know what this implies). It means that someone is hosting an email server for you, and you connect to that service regularly to check for new messages. A DIDComm Mediator isn't much different. It is a hosted service to which you connect to receive your messages, such as your credentials. However, instead of using an email client, we connect with our identity wallet, which communicates using DIDComm instead of IMAP, POP3, and SMTP. Also, we use Decentralized Identifiers (DIDs) instead of email addresses. Therefore, if you want to send a message to someone else's wallet, you need the other party's DID. Resolving the DID into a DID-Document gives you the 'Endpoint' of the other party, to which you can send a message. This endpoint could be, for example, <https://mediator.blocktrust.dev/>, our current Mediator implementation. This ultimately means that everyone needs their own mediator if they use their own wallet, like our identity wallet at <https://blocktrust.dev/IdentityWallet>. There is a small exception to this rule: If you use a hosted cloud wallet, you might not strictly need one. However, using a hosted cloud wallet is akin to using Gmail. All your data, including your cryptographic keys, reside with a single provider. But really, who wants that?
The state of development
Given that DIDComm and DIDComm Mediators are relatively new concepts, there aren't many available implementations currently. The majority are indeed within the Cardano Ecosystem. It began with a project from RootsID, followed by our Blocktrust Mediator, and, as of a few weeks ago, the PRISM team is also developing a Mediator. So, why should a Mediator be funded when there are currently three implementations? The answer is simple: <u>all of them are in a proof-of-concept state</u>. Our team recently demonstrated the interoperability between our wallet, our mediator, a PRISM PoC app for chatting, and the RootsId wallet at the Internet Identity Workshop (IIW) in April this year. While these basic scenarios involving three different participants mostly worked, it's now time for the next step:
Moving into production.
A solution that functions most of the time isn't sufficient for a large user base consisting of hundreds, thousands, and hopefully even more users in the near future. The code needs refining to cover not only the happy path, ideal scenarios when everything works but also to provide useful assistance when things go wrong, such as when a message is incorrectly formatted.
Moreover, none of the current mediators feature a UI that allows users to view how many messages are stored for them or their tenants, or to determine how much space these messages occupy on disk. Currently, there is also no convenient method for backing up messages or transferring them to another mediator. While we often take these features for granted in email servers, existing DIDComm Mediators aren't there yet.
We'd also like to enable WebSocket connections to a Mediator, negating the need to constantly check for new messages.
Additionally, creating an open-access Mediator (i.e. using it without without any restrictions) isn't a viable solution for a production application. The ability to create and manage different tenants (i.e., users), allocate space and resources to them all through a UI and an API is essential. This will allow the construction of service offerings around a mediator, contributing to a maturing and competitive ecosystem.
Finally, all these developments need to be reviewed and undertaken in an open-source manner. You can view the code of our current implementation here: <https://github.com/bsandmann/blocktrust.Mediator>
The ultimate goal of this proposal is to create a mediator that someone could simply set up on their own server or in the cloud.