Skip to content

feat(store): add createRwFile API and self-contained rw metadata management#445

Draft
kisielewski wants to merge 1 commit into
feat/chunk-read-write-optimization-for-search-apifrom
feat/random-write-metadata
Draft

feat(store): add createRwFile API and self-contained rw metadata management#445
kisielewski wants to merge 1 commit into
feat/chunk-read-write-optimization-for-search-apifrom
feat/random-write-metadata

Conversation

@kisielewski

Copy link
Copy Markdown
Member

Summary

  • Add StoreApi::createRwFile() — creates an empty random-write file directly, without streaming chunks; ready for read/write access via openFile immediately after creation.
  • Refactor FileHandler to own its dynamic metadata entirely — replace FileInfo/FileMeta/DecryptedEncKey/FileMetaEncryptor dependencies with a lightweight StaticMeta struct. FileHandler now computes and signs rwMeta JSON on every flush using its own file key.
  • Simplify FileHandler::sync() to take no arguments — fetches current rw state from the server autonomously via storeFileRwPull.
  • Simplify FileHandler::updateOnServer() — accepts only newEncryptedFileSize; builds and signs the full rwMeta internally.
  • FileReadWriteHandle now calls storeFileRwPull on open to bootstrap state, replacing reliance on pre-fetched EncryptionParams.
  • Synchronize Server API struct and method names with the bridge: StoreRwFile*StoreFileRw*, fields version/metarwVersion/rwMeta in StoreFileRandomWriteMeta, StoreFileRwPullResult extended with optional store and file fields, StoreFileReadModel extended with optional rwVersion.

…gement

Introduce createRwFile() — a new public API method that creates an empty
random-write file directly, without streaming chunks. The file is ready
for read/write access via openFile immediately after creation.

Refactor FileHandler to own its dynamic metadata entirely: replace the
FileInfo/FileMeta/DecryptedEncKey/FileMetaEncryptor dependencies with a
lightweight StaticMeta struct (fileId, resourceId, cipherType, chunkSize,
key). FileHandler now computes and signs the rwMeta JSON on every flush
using its own file key, and pulls the current server state via
storeFileRwPull instead of receiving it as parameters.

Simplify FileHandler::sync() to take no arguments — it fetches fresh rw
state from the server autonomously. Simplify updateOnServer() to accept
only newEncryptedFileSize; it builds and signs the full rwMeta internally.

FileReadWriteHandle now calls storeFileRwPull on open to bootstrap the
rw state, replacing the previous reliance on pre-fetched EncryptionParams.

Server API: add storeFileRwPull, storeFileRwCreate, storeFileRwWrite
methods with updated struct names (StoreFileRw* convention) and field
names matching the bridge (rwVersion, rwMeta).
@kisielewski kisielewski self-assigned this May 29, 2026
dmForSigning->set("serverSize", dmServerSize);
dmForSigning->set("size", dmSize);
dmForSigning->set("version", newVersion);
std::string rawSignature = privmx::crypto::Crypto::hmacSha256(

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JSON serialization is not deterministic across libraries — key ordering, whitespace, and encoding of special values can differ between Poco (C++), and bindings in JS, Java, Swift, C#. Since this string is the HMAC input, any subtle difference breaks signature verification on the other end.

Worth considering a deterministic format, or simply signing a manually constructed string with fields in a fixed order (e.g. size || serverSize || version || hmac).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant