Persist messages over application restarts

[jleach]

As part of creating a highly available mediator we want to be able to persist messages over restarts of the pod. This should include a technology capable of scaling as we implement other high availability features such as horizontal pod scaling.

[jleach]

@genaris I was thinking of using this to base the functionality of this feature. My though was to just use Redis or the existing PostgreSQL as the message store for now. Thoughts

Cc: @TimoGlastra

[TimoGlastra]

Redis (AFAIK) is more for caching, and there's not always a guarantee messages will be persisted. So I lean more towards something like PostgreSQL. I think using the libraries from @genaris make a lot of sense.

Would be great if we can do this is coordination with @genaris to make sure we keep all the important features they implemented.

[TimoGlastra]

Also -- I think we need to update this repo to a monorepo structure to allow deployment of packages to npm.

We usually take this appraoch nowadays:

• apps/* -> all the apps for the repo. In this case the mediator will be the only app
• packages/* -> all the packages (that can be dependent upon by apps) for the repo. We can add the pacakges from @genaris his repo to this.

One thing I want to be cautious of is that we make sure we combine all the packages in a clean manner. We are combining work from Animo/Credebl/2060 and such things tend to become messy if not enough time is spent on cleanup.

I can help with the monorepo setup, as I have done this numerous times already for public and internal projects (set up apps, and release pipelines for the packages)

[jleach]

@TimoGlastra @genaris Should we bring the changes in here or just use them from a published (from 2060.io) npm repository? Also, I did have some questions about the complexity of that package. Rather that just having the mediator talk to the persistent storage, it abstracts this behind a server. It also uses both Redis and Mongo which gives us three backing stores once you include Postgres. It for sure gets the job done but I wonder if we need to go from 1 service to 4 just to persist messages?

[genaris]

I think we can bring here at least the postgres package, which is a simple implementation that allows a multi-instance setup and the only extra component it needs is a PostgreSQL database, which could be at the same service than the one used for Credo wallet.

I'm working on improving the documentation to make its goals easier to understand. Take a look at https://github.com/2060-io/message-pickup-repository/tree/chore/separate-apps-packages/packages/postgres.

There is a lot of room for improvements but I think it is a better solution than the one this repo uses now (based on Askar storage), so it could be a good idea to integrate it into this repo's base agent. Here's an actual implementation using it (optionally, since it also supports the more complex one that you mentioned, which is under development): https://github.com/2060-io/didcomm-mediator/blob/main/src/agent/initDidCommMediatorAgent.ts

[TimoGlastra]

I think postgres outside of askar storage should be enough for most deployments, and is a good base.

[genaris]

Now that we have turned this repo in a monorepo we can bring the postgres package from Message Pickup Repository. @gabrielmatau79 will open a PR for this.

Meanwhile, I'll work on the adaptation of this repo's mediator to use it.