document/ARCHITECTURE.md

Art DAG Architecture

Overview

Art DAG is a content-addressed creative system with federated ownership. It separates rendering (L1) from social/ownership (L2), enabling distributed creative work with automatic attribution and revenue sharing.

Two-Layer Architecture

Level 1 - Rendering Layer

L1 Server (Celery workers)

• Executes rendering jobs
• Records provenance in the DAG
• Returns content-addressed outputs (SHA3-256)
• Stateless, horizontally scalable
• Most renders are junk/experiments - that's fine

L1 Client (AI-assisted front-end)

• "Make me a video that rotates" → AI designs config
• Sends configs + assets to L1 server
• Receives rendered output with provenance
• Decides what's worth keeping

Level 2 - Social/Federation Layer

L2 Server (ActivityPub)

• Ownership registry: "I made this with X, Y, Z"
• Federation: follow/followers across the fediverse
• Web UI: creators share their work
• Revenue distribution: ads flow down provenance chain
• Only shared content is persistent (curated from L1 junk)

Key insight: L1 produces lots of experimental renders. L2 is where the creator decides "this is the good stuff" and shares it via ActivityPub. Persistence = intentional sharing.

Data Flow

User prompt: "make me a cat video"
         │
         ▼
   ┌─────────────┐
   │  AI Client  │  Designs config from natural language
   └─────────────┘
         │
         ▼
   ┌─────────────┐
   │  L1 Server  │  Renders, records provenance in DAG
   └─────────────┘
         │
         ▼
   User reviews output
         │
         ▼ (if good)
   ┌─────────────┐
   │  L2 Server  │  Shares via ActivityPub, registers ownership
   └─────────────┘
         │
         ▼
   Federated web (followers see it)

Provenance Chain

Every output knows its lineage:

{
  "output": {"name": "cool-video", "content_hash": "abc123..."},
  "inputs": [
    {"name": "cat-footage", "content_hash": "def456..."}
  ],
  "effects": [
    {"name": "effect:glitch", "content_hash": "ghi789..."}
  ],
  "infrastructure": {
    "software": {"name": "infra:artdag", "content_hash": "..."},
    "hardware": {"name": "infra:render-farm", "content_hash": "..."}
  }
}

Revenue Model

How money enters

• Advertising on L2 server web interface
• Premium features (faster rendering, more storage)
• Direct payments for outputs (commissions, licensing)

How money flows

Revenue splits down the provenance chain:

Ad revenue from video view
    │
    ├── 40% → footage creator (input)
    ├── 25% → effect author
    ├── 20% → recipe/config designer
    └── 15% → L1 render infrastructure

Exact splits could be configurable per-output or protocol-defined.

Trust and Federation

Honourable L2 servers:

• Distribute revenue fairly down provenance chain
• Respect attribution
• Federate openly

Dishonourable L2 servers:

• Keep revenue for themselves
• Strip attribution
• Get "sent to Coventry" - defederated by peers

Self-policing network like Mastodon instance blocking. Reputation matters.

Proof of Creativity

Unlike Proof of Work (burn electricity) or Proof of Stake (lock capital):

Proof of Creativity = your contribution is measured by downstream usage

• Make useful footage → gets used → you earn
• Write clever effects → gets used → you earn
• Design good recipes → gets used → you earn

Not artificial scarcity. Not speculation. Actual creative value.

Why share here vs Facebook/YouTube?

Facebook/YouTube:

• You upload → they own it
• Their algorithm decides visibility
• They monetize, you get scraps
• They can delete/demonetize anytime
• Your audience belongs to them

Art DAG (federated):

• You publish → you own it (cryptographically signed)
• Your server, your algorithm
• Provenance ensures fair payment
• Nobody can delete your work
• Your audience connects directly to you

Repository Structure

GitHub (gilesbradshaw/art-dag)
    └── Core primitives: DAG, signing, ActivityPub, effects

git.rose-ash.com/art-dag/
    ├── registry    → Asset registry + signatures
    ├── effects     → Effect implementations (dog, etc.)
    ├── recipes     → Render scripts
    ├── art         → Rendered outputs
    ├── celery      → L1 distributed rendering
    └── document    → This documentation

Technical Foundation

• Hashing: SHA3-256 (quantum-resistant, full 64 char)
• Signing: RSA-2048 with RsaSignature2017
• Federation: ActivityPub protocol
• Identity: @user@domain.com format
• URLs: Immutable via git commit hashes
• Rendering: Celery + Redis for distributed jobs