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)
```

## Effects and Recipes

**Effects** are atomic transformations:
- `effect:identity` - returns input unchanged
- `effect:dog` - ignores input, returns dog.mkv
- `effect:glitch` - applies glitch effect
- Registered with content hash, owned by creator

**Recipes** are compositions of effects:
- A single effect IS a recipe (the simplest case)
- Complex recipes chain/branch multiple effects into a DAG
- Registered with content hash, owned by creator
- Recipe composer earns when their recipe is used

```
Simple recipe:    input → effect:dog → output

Complex recipe:   input ─┬→ effect:resize ──┬→ effect:overlay → output
                         └→ effect:glitch ──┘
```

Both effects and recipes are registered assets. Both creators earn from downstream usage.

## Provenance Chain

Every output knows its lineage:

```json
{
  "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)
- **Storage fees** to retain ownership:
  - Free tier: platform gets rights, can publish to YouTube/monetize elsewhere
  - Paid tier: you keep full ownership
  - Honest trade, not hidden in ToS
- **Render quality fees** (L1 server):
  - Free: watermarks, limited resolution, limited length
  - Paid: clean output, full resolution, no limits

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