# Phase 2: Universal Screen Recording

Phase 2 extends attribution to closed-source software through screen recording. While Phase 1 captures commands, Phase 2 captures pixels, heavier, but universal.

**Core Stack:** Rust (Client), Solana/Anchor (Registry), Arweave (Video Storage), AWS KMS (Identity)

### **Architecture Overview**

<figure><img src="/files/2Oq6nBdgOxYtYgKB5bxq" alt=""><figcaption></figcaption></figure>

The system operates under a hybrid Client-Server-Chain architecture. Proof of creation is captured locally with high performance, orchestrated via the cloud for fluid UX, and settled on blockchain for immutability.

The critical component is the Recorder Core, developed in Rust. It operates invisibly as a daemon, running continuously as a background process, while respecting user privacy.

### Capture Technology: Smart Variable Frame Rate (S-VFR)

Unlike traditional video recorders, the system records Context Events:

1. **Context Filter (Whitelist):** Recorder remains in standby. Only activates when a whitelisted window gains focus (Blender, Photoshop, VS Code, etc.)
2. **Input-Driven Capture:**
   1. Monitors global hooks (Mouse, Keyboard, MIDI, Wacom Tablet)
   2. If `Delta_Pixels < 1%` AND `Input_Events == 0` for > 5s, enters Logical Pause
   3. This results in video files that are 90% smaller than linear recordings

### Local Integrity (Merkle Tree)

To prevent data corruption in long sessions:

* The video is sliced into **Chunks** (10MB).
* Each Chunk generates a Hash.
* Hashes form a **Merkle Tree** in real-time.
* The system saves snapshots of the `Merkle Root` locally. If the PC crashes, the partial proof is recoverable.

### **Identity Management and Security (KMS)**

The application uses a **Silent Custodial Wallet** model to eliminate entry barriers (Seed Phrases).

Key Architecture:

* **Generation:** Private keys (Ed25519) are generated inside a cloud-based **HSM (Hardware Security Module)** (AWS KMS or Google Cloud KMS).
* **Isolation:** The private key never leaves the HSM. Neither the developers nor the API database have access to it.
* **Signing:** The API sends the Transaction Hash to the KMS -> KMS signs it -> API receives the signature and broadcasts it to Solana.
* **Sovereignty:** The system must include an "Eject Wallet" function, where the KMS exports the private key once to the user, should they wish to assume full self-custody in the future.

### **Lineage Tracking (File System Watcher)**

This module creates the asset family tree (parent/child relationships).

**Detection Logic:**

1. **Monitoring:** The Daemon uses native APIs (`ReadDirectoryChangesW` on Windows, `FSEvents` on Mac) to watch work directories.
2. **Fingerprinting:** Upon detecting a `FILE_SAVE` event, it calculates the SHA-256 Hash of the file.
3. **Link:** The system generates a local record linking: `[File Hash] <-> [Recording Session_ID]`

### Asynchronous Collaboration (Sidecars)

When a file moves between users:

* The system scans for attached metadata (Sidecar JSON or embedded Metadata).
* If User B imports a file created by User A, B's Recorder reads the original hash.
* In the final registry, B's asset is marked as "**Derivative Work**", pointing to the Solana address of A's asset.

### **Collaboration Architecture**

#### Synchronous Collaboration (Multiplayer)

*Use Case:* Teams working simultaneously in Figma, Google Docs, or Unity Multiplayer:

1. **Handshake Protocol:**
   1. **Host:** Initiates session and generates a `Session_UUID`.
   2. **Guests:** Enter the `Session_UUID` into their recorders.
   3. **Sync:** A lightweight WebSocket maintains timestamp synchronization between participants.
   4. **Multi-Sig Registration:** Instead of multiple isolated records, everyone's videos are grouped, and a single Asset is created on Solana. The `collaborators` field stores the list of involved wallets and their split %.

#### Asynchronous Collaboration (Sequential/Remixing)

*Use Case:* User A creates a 3D Model. User B downloads it next week to paint textures:

1. **The "Sidecar" Transport:**
   1. When User A exports a file, the Recorder generates a metadata sidecar (e.g., `model.obj.meta` or embedded XMP).
   2. Content: `{ "original_creator": "Wallet_A", "asset_hash": "0xABC..." }`.
2. **Lineage Handshake:**
   1. User B imports the file. User B's Recorder scans the folder.
   2. It identifies the Hash/Sidecar of User A.
   3. The system flags the new session as a "**Derivative Work**".
3. **Blockchain Pointer:**
   1. In the final Solana Registry for User B, the `parent_asset` field is filled with User A's Asset Address.
   2. This builds a **Directed Acyclic Graph (DAG)** of attribution, allowing royalties to cascade down to original creators.

### **API Orchestration**

#### Persistence Flow:

1. **Ingestion:** The Client sends the encrypted video to an S3 Bucket (via Presigned URL).
2. **Queue:** A worker (BullMQ) picks up the job.
3. **WORM Storage:** The worker sends the video to Arweave through a Bundler (Irys).
   1. *Why Bundler?* Ensures instant upload and payment in stablecoin, avoiding native Arweave network latency.
   2. *Return:* Receives an `Arweave_TxID` (permanent link).
4. **Blockchain Registration:** The worker assembles the Solana transaction with metadata and requests a signature from the KMS.

#### **Blockchain Data Structure**

```rust
#[account]
pub struct AssetAccount {
    // Authority and Identity
    pub authority: Pubkey,              // Creator's Wallet (KMS)
    pub timestamp: i64,                 // Registration Date (Unix)
    
    // Proof of Process
    pub fingerprint: [u8; 32],          // SHA-256 Hash of Final File
    pub arweave_proof: String,          // Link to video on Arweave
    
    // Lineage and Collaboration
    pub parent_asset: Option<Pubkey>,   // Pointer to Parent Asset (if any)
    pub collaborators: Vec<Collaborator>,
    
    // Technical Context
    pub software_context: String,       // E.g.: "Blender 4.1 / Win11"
    pub device_hash: [u8; 32],          // Hardware Fingerprint (Anti-Fraud)
    
    // AI Attribution
    pub ai_attribution: Option<AiData>,
}

#[derive(AnchorSerialize, AnchorDeserialize, Clone, Debug)]
pub struct Collaborator {
    pub address: Pubkey,
    pub role: String,                   // "Illustrator", "Animator"
    pub share_bps: u16,                 // Basis points (5000 = 50%)
}

#[derive(AnchorSerialize, AnchorDeserialize, Clone, Debug)]
pub struct AiData {
    pub is_ai_generated: bool,
    pub model_name: String,             // E.g.: "Midjourney v6"
    pub prompt_hash: [u8; 32],          // Hash of prompt used
}

```

#### **Verification and Zero Knowledge (ZK) - Future Scope**

To allow asset validation without revealing the raw video (trade secret).

The ZK Verifier will receive as **Private Input**:

* The decrypted video.
* The list of digital signatures from the software (proving the video shows genuine Photoshop, not a simulator).

And as **Public Input**:

* The Final File Hash.
* The Creator's Public Key.

**Output:** `True` (The video proves this creator generated this file using this software).

#### **Mobile Considerations (Android/iOS)**

* **Android:** The Recorder runs as a Service with `USAGE_STATS` permission to detect active apps and `MEDIA_PROJECTION` to record the screen.
* **iOS:** Due to "Sandboxing," automatic global recording is not permitted.
  * *Solution:* Implement as a **Broadcast Upload Extension**. The user must open the Control Center and start recording by selecting our App. The App processes the video stream in chunks, identical to the desktop logic.
  * *Physical World (Camera):* The iOS/Android App will have a "Work Camera" mode, which records video with timestamps and gyroscope/GPS data to prove the painting/sculpting was done at that location and time.

#### **Data Flow Summary**

| **Data**            | **Origin**        | **Intermediate Storage** | **Final Destination** | **Ownership**   |
| ------------------- | ----------------- | ------------------------ | --------------------- | --------------- |
| Creation Video      | Recorder (Client) | S3 (Temporary)           | Arweave (Encrypted)   | Private (Owner) |
| Asset Hash          | File Watcher      | API DB                   | Solana Account        | Public          |
| Metadata (Software) | OS Hooks          | API DB                   | Solana Account        | Public          |
| Private Keys        | KMS (Generator)   | HSM (Memory)             | HSM (Never leaves)    | Custodial       |

#### **User journey**

<figure><img src="/files/HAQzSIMr1ANw1fTgu98t" alt=""><figcaption></figcaption></figure>

***


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://anitya.gitbook.io/lightpaper/technical-deep-dive/phase-2-universal-screen-recording.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.