# Build Compatibility and Encrypted Outputs

This project is fully open source.
However, **official builds and community-built binaries are not guaranteed to be mutually compatible in all output formats**, particularly when encryption is involved.

## Build-Time Identity

Certain features rely on **build-time injected parameters** (such as signing or encryption identities) that are **not included in the public source repository**.

* Official releases are built in a controlled environment with private build parameters
* Community builds are created without these parameters
* Both use the same source code, but differ in **build-time identity**

This difference is intentional and limited to identity-related behavior.

## Build-Time Injected Keys

The project supports **build-time key injection** (via Go `-ldflags -X`), so private build identities can override default open-source keys **without changing source code**.

This mechanism is used by:

* Signature authorization flow keys (F/K/Y/N)
* Signature management encryption keys (A/B)
* Album export encryption keys (versioned XOR keys: v1/v2)
* Album config encryption seed (FixedSecret used for key derivation)
* Album `signature` field inner encryption key

For local/private builds, see:

* `sdk/private_keys.template.env`
* `sdk/setup_build_env.sh`

---

# Encrypted Output Compatibility

The application can produce **encrypted output artifacts** to protect user intellectual property.

Because encryption keys are **derived from the build identity**:

* Encrypted outputs generated by:

  * an official release **cannot be imported into** a community-built binary
  * a community-built binary **cannot be imported into** an official release
* This incompatibility applies **only** to encrypted outputs
* Unencrypted outputs remain fully interoperable across builds

This design prevents encrypted user artifacts from being trivially transferred between unrelated build identities.

---

# Design Rationale

This approach exists to balance three goals:

* **Open source transparency**
  All encryption logic and implementation are fully open and auditable.
* **User content protection**
  Encryption makes selected outputs less trivial to reverse, tamper with, or redistribute.
* **Clear trust boundaries**
  Build identity determines which artifacts are considered compatible.

No hidden logic, backdoors, or undisclosed capabilities are introduced by this mechanism.
The distinction exists solely at the **output compatibility level**, not at the source code or runtime behavior level.

---

# What This Is *Not*

* ❌ Not a DRM system controlling application usage
* ❌ Not a restriction on compiling or modifying the software
* ❌ Not a mechanism to hide functionality or behavior

Encryption affects only how **specific user-selected outputs** are packaged and later consumed.

---

# Summary

> Community builds and official releases share the same codebase but have different encryption identities.
> Encrypted outputs are intentionally not interchangeable across those identities.