Solidus Relay vs push notifications and message brokers
"We already have a queue" and "we already have push" are the two most reasonable objections to adopting a mediator, and both are sometimes right. This page says when.
When a push service is the better answer
Use APNs, Firebase or an equivalent when the job is waking an app. They are built for exactly that, they are free or near-free at most scales, they integrate with the platform's battery and delivery behaviour, and they work when your app is not running in a way nothing else does.
A mediator does not replace push. If your agent is a mobile app, you will likely want both: push to wake it, and a mediator holding the actual encrypted messages for collection once it is awake.
Where push is not enough: it terminates at a platform vendor, it is not a transport for authenticated agent-to-agent messages, and payloads pass through infrastructure you do not control in a form that vendor can read. If the content matters, push is a doorbell, not a mailbox.
When a message broker is the better answer
Use Kafka, RabbitMQ, SQS or similar when both endpoints are yours. Inside one system, a broker is better than a mediator in essentially every dimension: throughput, ordering guarantees, replay, tooling, operational maturity. A mediator would be a downgrade.
Brokers assume a trust domain. You own the broker, the producers and the consumers; the broker reads messages to route them, and that is fine because it is all one system.
Where a broker stops fitting: the moment the other party is not yours. Cross-organisation messaging over a broker means someone runs it, that someone can read the traffic, and both parties must agree on their infrastructure. That is a governance problem, not a technical one, and it is where the shape changes.
What a mediator is actually for
Two parties who do not share a trust domain, exchanging messages neither the mediator nor anyone else can read, when neither is reliably online.
- Identified by DIDs, not by accounts on someone's platform.
- End-to-end encrypted, so the intermediary is not a party to the content, the forward message and routing keys.
- Asynchronous, so neither side must be up when the other sends.
- Substitutable: change mediators by republishing a routing key. Neither party is locked to an operator.
That last property is the one brokers and push services structurally cannot offer, because in both the intermediary is the relationship.
The honest comparison table
| Push service | Message broker | DIDComm mediator | |
|---|---|---|---|
| Best at | Waking an app | High-throughput inside one trust domain | Cross-domain async messaging |
| Reads your payload | Yes, the vendor can | Yes, by design | No, holds no key |
| Both parties must agree on it | No | Yes | No, either side may swap |
| Sees metadata | Yes | Yes | Yes, see below |
| Maturity | Very high | Very high | Early; ours is beta |
Note the row that is the same everywhere. All three see routing metadata. A mediator's advantage is confidentiality of content and substitutability of the intermediary, not invisibility. See what a mediator can and cannot see.
Choosing
Push to wake an app. A broker when both ends are yours. A mediator when they are not, and the content must stay private from the infrastructure carrying it. Often push and a mediator together, doing different jobs.
If you conclude you do not need a mediator, that is a legitimate outcome of reading this page, when you do not need a mediator.
Relay implements Coordinate Mediation 2.0 and Pickup 3.0; no independent DIDComm conformance suite has been run, so "implements" is the claim and "conformant" is not.