Skip to content

Your private archive

Uploading gives you a free, off-computer copy of every complete session, checked on arrival (a complete demo replay must match the reference). Once a recording is in your archive, brisk prune DIR deletes the local copy (after checking its SHA-256 against your archive) and brisk pull brings it back, on this computer or any other. Uploading also gives you the cloud API and its OHLCV bars, which exist only there. Each upload is filed under archive/OWNER/YYYYMMDD/FROM-TO-SHA256 (the prefix brisk list returns), FROM and TO being the recording's first and last source clock (JST, HHMMSS), so a day's recordings sort by time.

Uploads are private: only you can list, download or delete them. There is no account. The first time it needs one, the tool makes your identity, a random secret, and the archive files your uploads under a one-way hash of it, your owner ID. The secret is kept twice, in your system's credential store (the macOS Keychain or Windows Credential Manager) and in an owner-only file (~/.config/brisk/identity.json); each restores the other. When it is made, the tool shows its recovery code, 28 letters and digits: write it down. brisk identity --recovery-code shows it again, and brisk identity --recover CODE uses it on another computer (or set BRISK_IDENTITY). Keep it private: whoever holds it is you to the archive, and without it or a saved copy your uploads can't be reached. The archive's operator can access what it stores, as with any hosted service; see PRIVACY.md.

Uploads are on by default. The first time you record or start a live session from the command line, the tool shows what is uploaded and asks once (Enter accepts, n declines), and saves your answer. After that, every clean, complete session (or recording of a live feed) uploads automatically, without asking again. Where nothing can ask, in the Python API or a command run without a terminal, sessions upload by default and the tool says so once per process (a warning in Python), until you decide with brisk consent --accept or --revoke (briskapi.consent(accept=True) or revoke=True).

  • What a demo session uploads: local timing measurements (including your computer's clock, which shows when you recorded). A demo replay's market data is the same for everyone, so the archive keeps it once: a demo upload sends only its own timing table (about 0.4 MB instead of about 41 MB), the archive joins it to its verified copy of the demo's market tables, and brisk pull returns the complete recording, verified as before. (The very first demo upload to an archive sends the whole recording.) Your IP address is used only for rate limits, as a keyed hash.
  • What a broker session uploads: a timing summary (percentiles of decode time, data age at receipt and frame spacing, a stall count, the frame count, the trading date and the first and last minute; briskapi.Archive().timing() lists yours) and, once a trading day has ended, that day's decoded market recording: securities master, prices, quantities, books, trades, codes and local timing. Cookies, tokens and connection diagnostics are never uploaded. The day's trades also give you OHLCV bars in the cloud, built from your own recordings only (see below).
  • Opting out: --no-upload for one run (upload=False in Python); --no-upload-market-data (upload_market_data=False) uploads a broker session's timing summary but not its market recording (--output DIR keeps that); BRISK_UPLOAD=0 for every run in that environment; brisk consent --revoke for good.
  • Deleting and restoring: brisk delete PREFIX removes an upload from your archive, so you can no longer list or download it. For 30 days you can bring it back: brisk list --deleted shows what you deleted (with deleted_at and restore_until) and brisk restore PREFIX (also a timing report's key) restores it. After 30 days it can no longer be restored and is removed.
  • Partial replays (--limit-frames) are never uploaded. A broker feed you stop mid-day ends that day there and uploads what is left of it, and the part of a day before a lost connection is uploaded once the feed reconnects. A day a crash or forced kill cuts short is repaired with its end and uploaded too (the next time a feed starts, after a crash).