6.10.1 Introduction
Client Distribution describes how Moonitoring builds, signs and delivers the software it installs for customers, including the farm sync client. What a version contains (builds, manifests, chunks) is kept separate from who receives it (channels, releases).
6.10.1.1 Model notes¶
Publishing rules¶
- Moonitoring is the only publisher and is implicit: there is no publisher or tenant entity.
- Only MoonitoringUsers (see MoonitoringUser) operate here, according to the capabilities of their roles (see MoonitoringCapabilityEnum).
- Organizations (see Organization) and testers (see ReleaseTester) appear only as recipients of a channel, never as operators.
- What a version contains (ReleaseBuild, ReleaseManifest, ReleaseChunk) is separate from who receives it (ReleaseChannel, Release).
Who may receive software¶
Who may receive software. Every application has an audience (ReleaseApplication.audience): public, organization or moonitoring. A channel narrows within that audience with the same rule as an agent tool (AgentTool): required capabilities, required entitlement features, and an explicit list of recipient Organizations; none of them set means the whole audience. Tester groups (ReleaseTesterGroup) cut across all of it: a verified e-mail in a group of the channel may download whatever its audience, Organization or role. The rule is evaluated three times, on the download page, at enrolment and at every update check, so a caller who loses the capability, the entitlement or the tester seat keeps the build they have and receives no newer one.
Nothing private can be enumerated¶
- Nothing private can be enumerated. A channel, build, manifest or chunk the caller may not receive answers exactly as one that does not exist: same status, same body. Manifests and chunks are served only through short-lived signed URLs minted by the Release API after the rule passes; the storage is never listable, chunk names are hashes, and application slugs and build numbers never appear in a URL an anonymous caller can reach. Only the public audience is served by the CDN without a token.
- The installer is the one exception: the installer file of every application, whatever its audience, and its download links are open to anyone. A link names the application and a version label, never a build number, and the file carries no secret: the person signs in when it runs, and the content of the build is still served only after an enrolment that passes the channel's rule (ReleaseChannel).
- Immutable entities are never updated after creation; append-only entities only gain records, never lose them.
- Optional entities can be left out: the model works without them.
- Hashes here are SHA-256 or BLAKE3; never xxh3 or md5 (see RawMetadata,
RawMetadata.hash_type), which do not resist deliberate collisions.
6.10.1.2 Diagram¶
Entities of this domain, their subtypes and the references between them. References to other domains are listed on each entity page.
6.10.1.3 Entities¶
- ReleaseProject: The top-level grouping of the software we distribute.
- ReleaseApplication: An installable client of a project, such as the farm sync agent or the Console, with its own builds and channels.
- ReleasePlatform: A combination of operating system and architecture that a build can target.
- ReleaseDepot: A package of content with its own versions, such as the binaries for one platform, shared assets or a language pack.
- ReleaseApplicationDepot: States which depots compose an application, and how each one is installed.
- ReleaseChunk (immutable): A piece of a file, identified by its content, so identical pieces are stored once and shared by every manifest that contains them.
- ReleaseManifest (immutable): A complete snapshot of a depot: for each file, the chunks that rebuild it.
- ReleaseManifestFile (optional): One file of a manifest, kept only when search or audit by single file is needed.
- ReleasePatchArtifact (optional): A ready-made update that holds only the differences between two manifests of a depot, prepared for the most common upgrades.
- ReleaseBuild: A complete version of an application.
- ReleaseBuildDepot: Says which manifest a build uses for each depot of its application.
- ReleaseChannel: A lane of distribution for an application, such as stable, beta or internal.
- Release (append-only): The decision to distribute a build on a channel, with a rollout percentage, an approval and signed metadata.
- ReleaseChannelAccess (optional): Lists the Organizations that receive a channel of the organization audience.
- ReleaseSigningKey: The public half of a key that signs release information, so clients can check that it really comes from us.
- ReleaseSignedMetadata (immutable): A signed document that clients trust, stating for example which build is current on a channel.
- ReleaseMetadataSignature: One signature of a signed metadata document by one signing key.
- ReleaseEncryptionKey (optional): A reference to a key, held in the key management service (KMS), that encrypts confidential content.
- ReleaseInstallation: One installed copy of one of our applications, on a given platform and channel.
- ReleaseUpdateEvent (optional): One download or update: an installation moving from one build to another, or a signed-in person downloading an installer from the download page before any enrolment exists.
- ReleaseTesterGroup: A named list of e-mail addresses that may receive the channels it is attached to, whatever their audience, Organization or role: the internal and closed testing of the app stores.
- ReleaseTester: One e-mail address in a tester group.
- ReleaseInstallerArtifact (immutable): The one file a person downloads to install an application on a platform: the installer of
releases, made for one build of the application, with the roots of the application's listed channels inside it.