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

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

#[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

---