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.