feat(external-signer): add Visibility arg to file_prepare_upload (rc-2026.4.2)#54
Merged
jacderida merged 2 commits intorc-2026.4.2from Apr 22, 2026
Merged
Conversation
Adds an external-signer path for public uploads. When a PreparedUpload
is prepared with Visibility::Public, the serialized DataMap is bundled
into the payment batch (wave-batch or merkle) as an additional chunk.
FileUploadResult::data_map_address then carries the chunk address of
the stored DataMap, giving the uploader a single network address to
share for retrieval.
Motivation: ant-gui (the Autonomi desktop GUI) currently has to block
its Public upload option in the UI because no external-signer pathway
exists for publishing the data map — `data_map_store` internally calls
`pay_for_storage`, which hard-requires a wallet, and the chunk-storage
plumbing (`store_paid_chunks`, `chunk_put_to_close_group`,
`merkle_upload_chunks`) is pub(crate), so consumers on the
external-signer path cannot hand-roll it. Bundling the data map chunk
into the existing payment batch reuses the one-signature flow that
wave-batch and merkle already use for file chunks, which lets ant-gui
thread a `visibility` flag through its existing code path and re-enable
the Public option with no extra wallet round-trip.
- `Visibility::{Private, Public}` enum (default Private)
- `Client::file_prepare_upload_with_visibility(path, visibility)`;
the existing `file_prepare_upload(path)` now delegates with Private
for backward compatibility
- `PreparedUpload.data_map_address: Option<[u8; 32]>` carries the
address between prepare and finalize
- `FileUploadResult.data_map_address` is Some for public uploads
- Both `finalize_upload` and `finalize_upload_merkle` propagate the
field; no separate network call is needed because the data map chunk
is stored alongside the rest of the batch
- e2e test verifies Private leaves the address unset, Public records
it, and the recorded address matches the serialized data map
The internal-wallet path (`file_upload_with_mode`) is unchanged —
ant-cli continues to use `file_upload` followed by `data_map_store`
for its public upload flow.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Addresses review feedback: - **End-to-end round-trip test (wave-batch)**: a small file is prepared as `Visibility::Public`, signed via the testnet wallet, finalized, then retrieved using only `data_map_fetch(&data_map_address)` + `file_download`. Asserts the downloaded bytes match the original. This is the half of the contract the existing test didn't cover: not just that the address is recorded, but that it actually refers to a retrievable DataMap. - **`#[non_exhaustive]` on `FileUploadResult` and `PreparedUpload`**: adding `data_map_address` was already technically a breaking change for any downstream that struct-literal-constructed these; `#[non_exhaustive]` forecloses the same concern for the next field. - **`AlreadyStored` data-map-chunk visibility**: when the serialized `DataMap` hashes to a chunk that's already on the network (same file uploaded twice — plausible under deterministic self-encryption), the prepare step silently drops it from `prepared_chunks` while keeping `data_map_address = Some(addr)`. An `info!` now explicitly logs this, and the `data_map_address` doc comments clarify that `Some` means "retrievable", not "we paid to store it". Merkle-path round-trip was attempted but blocked on an upstream `WrongPoolCount` contract revert between `pay_for_merkle_tree` and the `PaymentVaultV2` contract — reproduces outside this PR's changes and is not caused by anything here. Removing the failing test; calling it out separately for follow-up so the pool-commitment / depth relationship can be investigated without holding up this PR. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #39 onto the
rc-2026.4.2release branch.#39 was accidentally merged into
main; this PR cherry-picks its twocommits onto
rc-2026.4.2so the Visibility work lands in the RC.Summary
feat(external-signer): add Visibility arg to file_prepare_upload(2da81fc)test: add round-trip coverage + polish FileUploadResult/PreparedUpload(586a129)Conflicts with rc-2026.4.2 resolved in:
ant-core/Cargo.toml— kept bothrmp-serdeandsaorsa-coredev-depsant-core/src/data/client/file.rs— kept bothVisibilityenum andUploadCostEstimatestructant-core/src/data/mod.rs— merged re-export list to include bothUploadCostEstimateandVisibilityTest plan
cargo check --all-targetspasses locally🤖 Generated with Claude Code