Peering
Antimatter groups data into domains: a capsule exists within a single domain (for how cross-domain data is handled, see Capsules and Bundles). When starting out, it may be convenient to encapsulate all of your data in a single domain. For more advanced use cases, such as cryptographic isolation between teams, organizations or customers in a multi-tenant system, you will usually want to switch to a multiple-domain model. For example, a SaaS company might have one domain per customer, letting them have distinct audit logs per customer, distinct capsule manifests, distinct encryption configuration etc.
Peering exists to make working with multiple domains easier. Instead of having to set up nearly identical read/write contexts in multiple domains and duplicate your configuration everywhere, you can instead configure them in one domain and import them into all of your other domains. In addition to configuration, it is often convenient to be able to query a capsule manifest or audit log across multiple domains. The following resources can be shared using the peering mechanism:
- Identity Providers
- Fact types (and their facts)
- Read contexts
- Write contexts
- Capabilities
- Domain policy
- Capsule Access Log
- Control Log
- Capsule Manifest
- Billing (e.g. a domain can forward its expenses to another domain)
- Admin contacts (e.g. communication can be forwarded to the contact of another domain)
More documentation about peering will be added soon. See the OpenAPI Spec and Python language docs for more information.