Project VOLPAROSSA Cloud

Your files, supported by a cooperative network.

An OpenCloud integration for Project VOLPAROSSA's DICN — Decentralized Intelligent Cooperative Network. The goal is to keep your files useful and reachable without requiring your own OpenCloud server to stay switched on.

Development status: private file import, browsing, new-file upload and recovery now pass scoped trials through the original OpenCloud Files interface and real VOLPAROSSA storage peers. In the latest trial, the interface uploads and encrypts a file, the core stores its fragments, and a restarted service and browser download it twice after the original source and one storage peer are stopped and local ciphertexts are removed. Reads preserve the stored copies; explicit retirement brings all provider charges back to zero.

This is an owner-local integration in development, not a complete replacement for an always-on OpenCloud server. Imported selections stay read only; an explicitly enabled owner-private upload space accepts new files. Accounts, sharing, writable synchronization and recovery on another device remain open. Upload setup, original trial and limits →

One core, private files

OpenCloud supplies the familiar file experience; VOLPAROSSA supplies shared networking, private storage and appropriate compute. Applications reuse the same compatible core service rather than running independent storage networks.

The planned file path is:

flowchart LR
    O[Your OpenCloud account] -->|Authorized file read| A[Your device]
    A -->|Encrypt files and catalog| C[VOLPAROSSA core]
    C --> P1[Storage peer A]
    C --> P2[Storage peer B]
    C --> P3[Other storage peers]
    P1 -->|Encrypted fragments| R[Your authorized device]
    P2 -->|Encrypted fragments| R
    P3 -->|Encrypted fragments| R
    R -->|Local decryption| V[File browsing and reading]

Loading

This diagram describes the integration target, not a completed data path. Peers must not receive readable files, filenames, directory catalogs or recovery keys. Private storage is separate from the public content cache and training data. Encryption alone cannot prove what a private file contains.

All applications will follow one core-owned redundancy policy, not different Cloud subscription tiers or per-file copy-count choices. The current core basis is two copies of each encrypted fragment on distinct providers. Physical remote usage, including recovery copies and counted overhead, determines the reciprocal storage contribution. Temporary replacement copies remain charged until the old copies are confirmed retired. Distinct identities alone do not prove independent failure domains or continuous availability.

More than keeping the file bytes

Storing fragments is only one part of keeping OpenCloud usable while its original server is off. Accounts, directory metadata, permissions, sharing and client synchronization must remain available too.

The demonstrated application milestones are private, source-off file browsing and owner-private uploads: import selected files or upload new ones to a separate private space, then recover and read them through the original Files interface after the synthetic source is stopped. This uses an owner-local recovery adapter, not ordinary OpenCloud account login; it does not prove complete compatibility with unmodified web, desktop or mobile clients.

Further integration points include:

• Encrypted selective synchronization, version history and conflict handling.
• Sharing with explicit recipients and revocable permissions, without exposing private content to arbitrary storage peers.
• Private search, previews and optional AI assistance on the owner's device or another explicitly authorized execution environment.
• Appropriate public-content caching, kept separate from private files.
• Durable notifications and availability information through the common core.

Architecture, boundaries and remaining work →

First executable slice: private file recovery

The new scripts/cloud-file.mjs command separates authorized import, storage placement and recovery. Only the encrypted file goes to storage peers; the per-file recovery key stays with its owner. Restoring never consumes the stored copy, contacts the DAV source as a fallback or overwrites an existing output.

import        Authenticated DAV → owner-private encrypted file and receipt
create        Encrypted file → core-owned fragment plan and owner journal
deposit       Encrypted fragments → authorized storage providers
restore       Storage providers → verified ciphertext → private owner output
restore-local Explicit recovery from a locally retained encrypted file

This command supplies file recovery, not an OpenCloud account or synchronization service. Names and source versions are encrypted inside each object. Imports temporarily use private plaintext staging on the owner's device; storage peers never receive that staging data.

Commands, configuration and recovery boundaries →

Source-off browsing: an encrypted catalog and local read service

cloud-catalog.mjs records an explicit owner selection after restoring and verifying each file. cloud-serve.mjs exposes that immutable private catalog through authenticated listing, file reads and ranges on loopback. File reads restore from the shared core, verify and decrypt locally, then remove their temporary plaintext; the original server is never a fallback.

The actual pinned OpenCloud Web SDK can exercise the DAV interface. The original OpenCloud Files application can also be built with a narrow recovery adapter: open the local service, enter its private access token and browse the explicitly selected files. It retains the original Files navigation and download controls, not an imitation file browser. This local recovery authority is visibly separate from an OpenCloud account; it grants no upstream identity, write or sharing rights.

The catalog and per-file recovery keys/journals currently remain on the owner's device; second-device recovery remains work in progress.

Run the private read service and see its evidence boundaries →

Build and open the original Files recovery interface →

Development

The dependency-free JavaScript runs on Node.js 24 or newer. Private-file tests also use the installed Linux Python 3.11+ and GnuPG tools (gpg, gpg-agent, gpgconf); nothing is downloaded or installed automatically:

node --test test/*.test.mjs

Local tests use synthetic loopback WebDAV fixtures and real local GnuPG. They do not install OpenCloud, contact an account, enable network participation or alter host network settings. The optional actual SDK check requires explicit pinned staging. Injected storage fixtures are labelled and are not peer-placement proof.

The separate protected-peer trial passed for Cloud 541cc826fe14ce69cf89a82ecb600ad14dd534c6 and core 41e404a40312f039827f761dea7b90be48d0c21f: authenticated synthetic source import, eight encrypted fragment copies on three providers, source and local ciphertext removed, provider A offline, two hash-verified recoveries from B/C, complete retirement/accounting and unchanged host networking. That trial predates the catalog/read-service additions and does not prove the full OpenCloud UI.

The subsequent SDK-to-peer trial passes for Cloud a67b91fbed42ecd23ba215eb21ef54397fc9f06a and core 5d9d347fc52e4cc13498ed3b6790d1f00de370c3. Four B/C reconstructions include catalog creation and actual SDK reads while source/local ciphertext/provider A are unavailable. All 32 required protected MPTCP/TLS exchanges, retained charges, all-copy deletion and unchanged host state pass. Exact-source replay of the 44 original artifacts also passes. Range reads currently restore the whole encrypted file before returning the requested bytes.

The subsequent original Files UI/peer trial passes for Cloud 63bba5d1163a69e1ee6b4218c9e7462d941f22f7 and core d7403106837962c66cd0af0e049236785d8053cb. With the source stopped, local ciphertext removed and provider A offline, six protected reconstructions from B/C serve the direct restore, catalog, SDK reads and two independently verified original UI downloads. Authentication denial, logout, non-consuming reads, all-copy retirement and unchanged host state pass. The earlier failed UI trials remain recorded in the recovery-interface evidence. That read-only milestone did not prove uploads.

The latest original upload and restarted-recovery trial passes for Cloud ffdcfaa15cdd2a029dae545904b0a58603da4e17 and core 929c2ff909f4e9704046459e0434006397dc9110. Original Files/Uppy uploads one new file; the core retains two copies of each of its four encrypted fragments. After restart, source shutdown, local-ciphertext removal and provider A's loss, two original UI downloads match the source bytes. Retained charges, all-copy retirement, private cleanup and unchanged disposable guest networking pass. See the scoped evidence; full accounts, sharing, synchronization and cross-device recovery remain open.

Upstream and licensing

The integration targets the production OpenCloud server v7.2.4, pinned to 1770793f2657e153836c32d32dd6d256b8531d3d. New original integration code is GPL-3.0-only. OpenCloud server uses Apache-2.0; its separate web client uses AGPL-3.0. Those component licenses remain distinct.

Source provenance →