SVs aspire to make everything that is visible to an SV operator be exposed publicly. Currently, that is not the case. They expose some data via Scan, mostly data from ledger API, e.g. transaction history via the Scan updates API.

The mediator is a component in Canton protocol that routes (encrypted) messages to and from recepients. It therefore has insight to metadata like who is talking to whom. We wish to make that data public

DA has recently added an API to the mediator called (for now) "Mediator Scan" API: https://docs.digitalasset.com/subnet/3.3/howtos/observe/mediator_scan.html, but that's still an API internal to the SV node, e.g. it does not support auth. We wish to expose this data further via the Scan app. The expectation is for the Scan app to ingest data from the Mediator Scan API, store it locally in its DB, and serve it externally from its own copy in that DB.

This would require writing some automation in the Scan app that ingests that data, designing a sensible DB schema for this data, and adding support for an API that serves it from Scan.
Non-requirements for this phase:

• BFT reads, i.e. no requirement for absolute consistency between different SV nodes (of course, the data will be consistent, but if there happens to be some counter that's local, at this phase we don't try to get rid of that).
• Backfilling. An SV node that joins later does not need (at this phase) to backfill data from other SVs. Just start ingesting data visible to it locally, and serve only that data.