One-to-many
One producer pushes a verifiable record to a bounded, named set of recipients.
One producer pushes a verifiable record to a bounded, named set of recipients.
Diagram
This diagram is free to copy into your own presentation. The dotted lines show each recipient verifying the record independently against the public audit layer.
When to use, when not to use
When to use. Use one-to-many when a single producer needs to deliver the same verifiable record to a known, enumerated set of recipients and each recipient should be able to verify it independently. The recipient list is defined in advance: parties are invited into the exchange, and delivery is a push from producer to each named recipient. This is the right pattern when the producer must know exactly who receives the record and when every recipient is admitted deliberately.
When not to use. If the set of readers is open rather than enumerated, and any admitted party should be able to subscribe and read without the producer maintaining a recipient list, use broadcast instead. If recipients should fetch a record only when they need it, rather than receive a push, use on-demand (pull).
Example configuration (YAML)
pattern: one-to-many
protocol_version: "0.1"
exchange:
topology: one-to-many
participants:
- public-body
- verifier
- retailer
admission: invited
delivery:
mode: push
ordering: per-topic
payload:
encryption: field-level
disclosure: selective
audit:
anchor: public-audit-layer
proof: per-recordUse case
This template fits a public-body or capture-source that issues a signed record to several named verifiers, illustrated by the content authenticity protocol, where a record is signed at the point of capture and delivered to the parties entitled to check it. The same template fits a retailer distributing a verifiable record to a fixed set of counterparties. It configures the base data-sharing protocol.