[andersalm]

The offline custodian can prepare one approved initial Community profile through the existing protected signer. The operation binds the exact unsigned profile and conversation grant to the operator policy, uses the existing maintainer PEM through pinned OpenSSL, and signs in the separate elastos.collaboration-network.profile.v1 domain. Public verification precedes the read-only output files.

The operation supports revision 1 and produces inert startup configuration and release-pin inputs. Runtime consumes those pins after the separately reviewed Community network-pin support is integrated. The operator owns production input approval, signing, publication and activation. Existing release/head and model-catalogue operations retain their domain and custody checks.

Refs #186. Published review source b6a582a74b129b40eaa6c19ff3aa7aed24a901fa, tree 53a7d46e91a9b93feff907731b18296f02688b7b, normally merges approved develop 792942b54a0383c1c484e22e5d076fcde33c7fc4 into the separate four-file signing operation. All four signing files remain byte-identical to independently reviewed 97fb63bb; the three earlier commits remain intact. Current validation passes 57 disposable-fixture signing tests with an existing protected interpreter, 102 product-data tests, product-data validation, diff checks and both Rustfmt checks. The ordinary canonical publication hook passes, including 2,845 Rust test executions with zero failures and 27 ignored; its receipt is f44db23685e5e71dc3c9a4438ab20afd3113ce7010b397a3ee2cce574b25e6c4. The exact remote head is verified. Required human review remains pending; this PR stays draft for that handoff.

Second seed upgrade and Community activation

OMP owns production placement, signing and activation. After #309 qualification and integration with #345, select one reviewed release source containing both changes. Record its commit/tree, successful develop CI run, Release package run and artifact digests, installed Runtime/provider hashes, approved maintainer DID and disposable preflight result. Anders and OMP approve the production inputs and each activation step before execution.

1. Prepare the separate Community role. Approve a dedicated service account, HOME, XDG data directory, stable UDP listener and resource-limited unit. Its Runtime data root is $COMMUNITY_XDG_DATA_HOME/elastos; the existing release service keeps its account, data and unit. Install verified artifacts to stable paths. The approved Community unit can use elastos serve --addr <approved-loopback-address> --storage-path <community-data-root>/storage, or elastos gateway --addr <approved-loopback-address> if OMP selects a gateway. OMP supplies the unit, permissions, resource limits and listener/firewall settings.

2. Boot and bind that Runtime. First start it in isolation, with its own HOME/XDG environment and the collaboration startup file absent. Record its identity and health. Stop its own unit, set the stable listener under the same account and environment, then restart the same isolated Runtime:

   elastos config set carrier_bind_addr <approved-free-UDP-bind-address>

   Verify the actual listener and retained identity before export. This command writes the selected XDG Runtime's config.toml. An occupied explicit listener stops startup.

3. Export its local bootstrap receipt. Write a new owner-only file from the selected running Runtime:

   elastos collaboration-config export-local-bootstrap-receipt \
     --data-root <community-data-root> \
     --runtime-kind operator \
     --output <new-owner-only-bootstrap-receipt>

   Use operator for serve; use gateway for an actual gateway process. The authenticated export binds the node and ticket. Operator placement and tickets stay private.

4. Approve and sign the initial profile offline. Prepare canonical community-profile-input.json from the approved network/conversation IDs, bootstrap receipt, existing maintainer DID, explicit trusted signer set and canonical default grant. The grant uses sender service chat and profile_scoped_signer. Approve the exact input, payload and grant hashes in a separate protected policy. Set revision 1 and previous_profile_sha256: null in that approval policy; the revision-1 signed profile payload omits the previous-profile field. Later revisions require a separately reviewed operation. The custodian runs:

   env -i <pinned-python> -I -S <installed-release-signer.py> \
     --operation community-profile --manifest community-profile-input.json \
     --policy <approved-policy> --input-root <approved-unsigned-input> \
     --output-root <new-output-directory>
   elastos collaboration-config verify \
     --input <new-output-directory>/collaboration-network-release-v1.json

   The paired collaboration-network-release-pin-v1.json supplies the exact head CID, network and signer set. Keep the production key in the existing protected custodian workflow.

5. Bind and publish the exact release inputs. Bind those exact startup-file bytes/CID and pin fragment to release preparation and signing. The current b6 release-publish.sh has no Community-file input, so reviewed pin/file admission must be integrated before the production release flow. Once that gate passes, use the existing commands:

   scripts/release-publish.sh prepare <PACKAGE_RUN_ID> <VERSION>
   scripts/release-publish.sh policy <VERSION> <SIGNER> <KEY> <OPENSSL>
   # The custodian reviews and runs the printed signer command.
   scripts/release-publish.sh seed <VERSION> <SIGNED_DIR>

   Verify the signed output and seed import through the disposable preflight before production approval.

6. Print and review the second release-unit upgrade. Build Release package with seed_package set, then run:

   scripts/release-publish.sh seed-upgrade <PACKAGE_RUN_ID>

   This prints the seed-side commands; OMP executes them only after approval. Private RELEASE_SEED_* inputs select the existing release role. Verify successful exact-source develop CI separately: b6's seed_upgrade() checks the artifact but does not call checked_ci(). The printed sequence verifies artifact digests/source, installs Runtime/IPFS/components, runs scripts/installed-provider-verify.sh --require-verified ipfs-provider, and restarts only $RELEASE_SEED_UNIT.

7. Approve Community and relay activation separately. OMP supplies the Carrier: any Home reaches any Home by DID on any network (seed relay) #345 activation plan: install the verified signed startup file and exact release pin, restart the dedicated Community unit, then prove stable identity/listener, release/update availability, direct delivery and the approved cross-network relay path. The release-unit upgrade does not create the Community unit or relay role. Production signing, seed changes and live activation each retain explicit approval.

The commands above are verified against this PR's b6 source: bootstrap/profile contract, config command, Runtime CLI, release workflow and seed upgrade. This records the procedure and required inputs; execution and relay implementation keep their separate owners.

[andersalm]

OMP is integrating this into branch feat/community-release-pin (merge of b6a582a) together with release admission of the signed Community file; that PR will say 'Part of #86' and this one closes when it opens. Status: #86 Road step 3.