Monorepo for Aesthetic.Computer aesthetic.computer

Fork 0

core reports bootloader-art-integration-feasibility.md

21 kB

Markdown

at codex/xbox-api-layer

prompt.ac/@jeffrey · feat: KidLisp Mini bundler for RBP-26 (~20 KB target) · 5mo ago

0986f414

Bootloader.art Integration Feasibility Report #

Date: 2026-04-14
Status: Research & Feasibility Analysis
Author: Claude Code

Executive Summary #

bootloader.art is an open experimental on-chain generative art platform that enables artists to create, mint, and collect unique algorithmic art pieces directly on the blockchain. It challenges traditional NFT immutability by supporting living, updatable code post-mint—meaning artists can evolve their pieces after they're tokenized.

Key Finding #

Integrating AC's KidLisp bundler with bootloader.art is technically feasible but constrained by on-chain storage limits. The integration would work best for:

KidLisp pieces (smaller, more optimizable)
Generative art focus (procedural over interactive)
Optimized bundles (<24KB on-chain, reference off-chain assets)

What is Bootloader.art? #

Platform Overview #

Purpose: On-chain generative art platform with mutable code post-mint
Code Storage: Directly on blockchain (with size constraints)
Update Mechanism: Artists can modify code after mint; collectors' pieces evolve
Ecosystem: Part of broader platforms like fxhash, Highlight XYZ, Art Blocks

Key Innovation: Living Code #

Unlike traditional NFTs where metadata is immutable, bootloader.art supports:

Post-mint code updates by artist
Evolutionary art: pieces change as the underlying algorithm evolves
Collector engagement: tokens become more valuable as code improves

Technical Architecture #

Uses HTML + JavaScript as core format
Code rendered client-side in browser
Seed-based generative output (each NFT gets unique seed)
On-chain storage of generative algorithm

Our Current Bundling Infrastructure #

Existing Bundlers #

1. Oven Bundler (`oven/bundler.mjs`) #

Purpose: Generate self-contained HTML bundles for AC pieces
Current Capabilities:

Bundles entire AC runtime into single HTML file
Supports both KidLisp pieces ($code) and JavaScript pieces
In-memory caching per git commit
Brotli compression for WASM decoder
Comic Relief font inlining
Minification support

Output: Typically 2-8 MB self-contained HTML (uncompressed)

Key Features:

- Core essentials: boot.mjs, bios.mjs, disk.mjs, kidlisp.mjs
- Graphics (2D/3D): graph, geo, 2d, gl-matrix, glaze
- Input handling: keyboard, gamepad, motion, touch
- Audio: sound libraries (speaker, synth, bubble)
- UI components: buttons, text input, ui.mjs
- Storage: store.mjs for persistence

2. KidLisp Bundler (`system/backend/kidlisp-bundler.mjs`) #

Purpose: Generate minimal KidLisp-specific bundles
Optimizations:

Explicit skip list (wasmboy, UDP, world system, optimizer)
Ultra-minimal file set for basic KidLisp visuals
SWC minification
Import rewriting for size optimization

Key Skip Files:

dep/wasmboy/ — 386 KB source (GameBoy emulator)
lib/udp.mjs — networking (dynamically imported)
systems/world.mjs — 3D features

Estimated Output: ~200-400 KB minified (before gzip)

On-Chain Storage Constraints #

Blockchain Size Limits #

Constraint	Value	Notes
Ethereum storage per txn	~128 KB	Hard limit for single transaction
Typical contract calldata	24 KB	Realistic limit for deployed code
Arweave bundling	100 KB+	More generous, but off-chain
Solana program size	200 KB	Program accounts must fit in this
Zora ERC721A calldata	4 KB+	Per metadata/code segment

Gas Cost Impact #

String manipulation: Major gas consumer in on-chain code
minification essential: Every byte counts
Gzip/Brotli: Not applicible on-chain (code must be decompressed off-chain)

Reference: Autoglyphs Precedent #

Autoglyphs (early on-chain generative art):

Algorithm fit in single Ethereum transaction (~13.27% of network capacity per mint)
Bare-essentials algorithm only
NO UI, NO audio, NO graphics libraries
Pure math-based SVG generation

AC Bundle Size Analysis #

Current Oven Output #

Full AC Runtime (uncompressed):  ~7-8 MB
├── boot.mjs                    ~15 KB
├── bios.mjs                    ~80 KB
├── lib/disk.mjs                ~572 KB (largest)
├── lib/kidlisp.mjs             ~90 KB
├── Graphics libraries          ~250 KB
├── UI/Input systems            ~180 KB
├── Audio systems               ~200 KB
└── Dependencies (gl-matrix, etc) ~100 KB

KidLisp Bundler (Optimized) #

Minimal KidLisp Bundle:         ~200-400 KB (minified)
├── Core runtime (boot+bios)    ~80 KB
├── KidLisp interpreter         ~65 KB
├── 2D graphics (no 3D)         ~45 KB
├── Essential UI                ~30 KB
└── Math & helpers              ~40 KB

Ultra-Minimal Bootloader Bundle Target #

On-Chain Optimized Bundle:      ~20-24 KB
├── Minimal AC boot strap       ~5 KB
├── KidLisp evaluator           ~12 KB  (pre-minified)
├── Graphics primitives         ~4 KB   (line, circle, rect only)
├── Color model                 ~1 KB
└── DOM rendering               ~2 KB

Feasibility Assessment #

✅ What Works Well #

KidLisp as Primary Target
- Interpreted language, smaller interpreter (~12 KB minified)
- No build step required (unlike JavaScript)
- Math-centric, good for generative art
- Already optimized in kidlisp-bundler.mjs
Seed-Based Rendering
- AC's pieces use params/colon input system
- Can expose seed-based variation similar to generative platforms
- KidLisp pieces already deterministic
Existing HTML Bundling
- oven/bundler.mjs proven in production
- Modular architecture (can strip down essentials)
- Font embedding, minification already in place
Graphics Stack
- 2D primitives (line, circle, box) can fit in 4-5 KB
- No dependency on WebGL for basic art
- Canvas API is lightweight

⚠️ Significant Challenges #

Size Constraints
- Full AC runtime: 7-8 MB (bloated)
- Realistic on-chain limit: 20-24 KB
- Gap: 97.3% reduction needed
- KidLisp-only path could get to ~200 KB (30x too large)
Disk.mjs Dependencies
- lib/disk.mjs is 572 KB (largest library)
- Contains UI, audio, networking, 3D graphics
- Would need complete rewrite of core API surface
- Risk: AC pieces depend on disk.mjs structure
Browser Context Limitations
- Bootloader.art renders in browser (not AC's WebSocket+module-loader model)
- No hot reloading infrastructure
- Pieces run in isolation, not linked to AC social system
- Would lose: networking, chat, multiplayer features
Asset Handling
- Fonts (ComicRelief): 20+ KB (can't fit on-chain)
- Audio files: not practical on-chain
- Images: not practical on-chain
- Would need off-chain asset references (IPFS/Arweave)
API Incompatibility
- AC pieces expect: { wipe, ink, line, circle, ui, sound, net, event, ... }
- Bootloader expects: deterministic, seed-based render(seed) → SVG/canvas
- Significant refactoring needed per piece

❌ What Doesn't Work #

Full AC Runtime On-Chain
- Simply impossible due to size
- Would require 300+ separate contracts or sharding
Audio/Networking Features
- Sound synthesis: 50+ KB of synthesizers
- Networking (socket.io): 30+ KB
- These are fundamentally off-chain
Interactive Game Pieces
- Pieces like squash.mjs, 1v1.mjs require multiplayer networking
- Bootloader is single-user generative only
- Would lose entire game category

Integration Approaches #

Approach 1: KidLisp-Only Ultra-Minimal (RECOMMENDED) #

Scope: Support only KidLisp pieces, no JavaScript
Target Size: 20-24 KB on-chain

Components:

bootstrap.mjs (on-chain)         ~2 KB
├── WASM loader shim
├── Initialize canvas/DOM
└── Invoke KidLisp evaluator

kidlisp-mini.mjs (on-chain)      ~12 KB
├── Minimal evaluator
├── Core functions (draw, color, math)
└── Skip: sound, networking, 3D

graphics-tiny.mjs (on-chain)     ~4 KB
├── line(x1, y1, x2, y2)
├── circle(x, y, r)
├── rect(x, y, w, h)
├── fill(r, g, b, a)
└── Canvas wrapper

piece-data.js (on-chain)         ~4 KB
└── Actual KidLisp code (usually 1-3 KB)

Total on-chain: 22 KB

Off-chain (referenced):
- Fonts (IPFS/Arweave)
- Optional: larger KidLisp libraries via dynamic import

Workflow:

1. Artist writes KidLisp piece on AC (or similar)
2. Extract & minify core KidLisp code
3. Create bootstrap + graphics shim
4. Deploy to bootloader.art with on-chain + IPFS refs
5. Piece rendered: seed → KidLisp eval → canvas → display

Pieces That Would Work:

$pie (generative visuals)
$cw (color work)
$cow (recursion/fractals)
$trees (procedural generation)
Any math-based generative KidLisp

Pieces That Would NOT Work:

squash, 1v1 (multiplayer)
Any piece using sound library
Pieces using net, chat, socket
Pieces using 3D (world.mjs)

Implementation Effort: Medium (3-5 days)

Fork kidlisp-bundler.mjs to bootloader target
Create minimal graphics shim
Implement seed → params conversion
Test with 5-10 existing KidLisp pieces

Approach 2: Off-Chain Code + On-Chain Metadata #

Scope: Store full bundle on IPFS/Arweave, reference on-chain
Target Size: 200+ KB off-chain (no on-chain size limit)

Components:

On-chain NFT metadata:
{
  "name": "piece-name",
  "image": "ipfs://...",           // preview image
  "external_url": "ipfs://...",    // full bundle URL
  "attributes": [
    { "trait_type": "size", "value": "205 KB" },
    { "trait_type": "seed_range", "value": "1-1000000" }
  ]
}

Off-chain (IPFS):
- Full AC runtime bundle (7-8 MB)
- OR KidLisp + minimal graphics (400 KB)
- Self-contained, no external assets

Workflow:

1. Generate HTML bundle with oven/bundler.mjs
2. Upload to IPFS (via Pinata, etc.)
3. Create minimal NFT metadata pointing to IPFS
4. Deploy to bootloader.art
5. User clicks → loads IPFS → renders AC piece

Advantages:

No size constraints
Can use full AC runtime + pieces
Works for JavaScript pieces too
Hot updates possible (re-upload to IPFS)

Disadvantages:

Code not truly "on-chain" (defeats bootloader.art philosophy)
Depends on IPFS availability
Centralization concern (if IPFS node goes down)
Not authentic to "generative on-chain" movement

Implementation Effort: Low (1-2 days)

Integrate IPFS upload into oven
Create metadata templates
Document process

Approach 3: Hybrid Hybrid: Small On-Chain + Large Off-Chain #

Scope: Seed + metadata on-chain, full code on IPFS
Target Size: 2-3 KB on-chain, 400 KB off-chain

Components:

On-chain contract:
{
  seed: 12345,
  ipfs_hash: "QmXxxx...",
  artist: "0x...",
  title: "piece-name"
}

Off-chain (IPFS):
{
  bundle: "full-ac-runtime.html",  // 7-8 MB
  code: "$code",                   // KidLisp source
  entry: "piece-name"              // which disk to load
}

Workflow:

1. Deploy minimal metadata on-chain
2. Full code lives on IPFS
3. Bootloader renders: load IPFS → seed → render
4. Updates: artist re-uploads new IPFS, points contract to new hash

Advantages:

Some on-chain component (immutable seed)
Updates possible (mutable code)
Full feature set available
Scalable approach

Disadvantages:

Still not "pure" on-chain
Requires contract interaction
More complex architecture

Implementation Effort: Medium (4-6 days)

API Constraints & Integration Points #

Bootloader.art Expected Interface #

Based on generative art platform conventions, bootloader.art likely expects:

// Input: window.seed (unique per token)
const seed = window.seed || 0;

// Output: canvas/SVG/HTML in DOM
// Deterministic: seed → same visual output every time

// Optional: window.tokenId, window.wallet for metadata
const tokenId = window.tokenId;
const wallet = window.wallet;

// Code is stored as HTML blob containing <script>
// No external requests expected (self-contained)

AC Piece Adaptation Required #

Current AC piece:

function boot({ wipe, ink, line, circle, screen, params }) {
  // AC-specific initialization
}

function paint({ wipe, ink, line, circle }) {
  // Render per frame
}

export { boot, paint, act, sim };

For bootloader.art:

// No "boot/paint/act/sim" lifecycle
// No parameterization beyond seed
// Single "render" function

function render(seed) {
  const rng = seedRandom(seed);
  // Use rng for all randomness
  
  // Draw to canvas
  // Return visual output
}

// Export as HTML with render() baked in

Missing Features in Bootloader Context #

Feature	AC	Bootloader	Notes
Networking	✅	❌	No socket.io, net API
Audio	✅	❌	Can't synthesize on-chain
Multiplayer	✅	❌	Single-user only
Persistence	✅	❌	No store.mjs
Hot reload	✅	❌	Static on-chain code
Piece discovery	✅	❌	Isolated on bootloader
Params/colon	✅	❌	Only seed-based
Analytics	✅	❌	No logging to AC backend

Generative Tokens: AC Angle #

What Are Generative Tokens? #

Generative tokens are NFTs where the artwork is generated algorithmically, with each token receiving a unique seed that produces a unique visual output. Platforms like fxhash, Art Blocks, and bootloader.art enable this.

AC's Unique Position #

Strengths for Generative Tokens:

KidLisp: Purpose-built for generative art (declarative, functional)
Existing Ecosystem: 500+ pieces already created
Community: Active artist community
Interactivity: Can create interactive generative pieces (if modified)

Weaknesses:

Runtime Size: 7-8 MB baseline (vs. 20-24 KB industry standard)
Not Designed For: Single-shot rendering (expects interactive loop)
Off-Chain Asset Dependency: Fonts, samples, etc.
Community Expectation: AC pieces are interactive/playable, not static

Generative Token Use Cases for AC #

Viable:

KidLisp Art Series: Pure math-based visuals (fractals, patterns, algorithms)
- Example: $cow (recursion) → mint as generative token series
- Example: $cw (color work) → seed-based palettes
Artist Collaborations: Art Blocks-style drops
- Mint 100 unique renderings of curated KidLisp piece
- Each with unique seed
- Artist retains code update rights via bootloader.art
Cross-Platform Bridges:
- Mint on bootloader.art
- Code stays on AC (via hot-reload)
- Collectors view on bootloader, play on AC

Not Viable:

Game Pieces: squash, 1v1, etc. (require multiplayer)
Interactive Sound Art: pieces with sound library
Real-Time Collaboration: pieces using net, chat

Recommendations #

Short Term (Feasibility Phase) #

Create KidLisp Bootloader Shim (1-2 days)
```
npm run create:bootloader -- --template=kidlisp-mini
```
- Fork kidlisp-bundler.mjs
- Target 20-24 KB on-chain bundle
- Test with 5 existing KidLisp pieces
- Document seed → params mapping
Evaluate 3 Candidate Pieces (1 day)
- $pie — static generative visual
- $cw — color palette generation
- $cow — fractal/recursive patterns
- Measure minified bundle size
- Verify deterministic seed output
Document bootloader.art Integration (1 day)
- API compatibility matrix
- Size reduction techniques
- Example adaptation (KidLisp piece → bootloader.art)

Medium Term (Proof of Concept) #

Deploy 1-3 Pieces to Bootloader
- Partner with bootloader.art
- Mint small test series (10-20 tokens)
- Gather community feedback
Implement Seed-Based Parameterization
- Map seed → existing params system
- Ensure deterministic output (no timestamps, etc.)
- Test across multiple browsers/platforms
Create IPFS Bridge (optional)
- Upload AC bundles to Pinata
- Create metadata templates
- Document off-chain approach

Long Term (Ecosystem Integration) #

Off-Chain Code, On-Chain Metadata
- Hybrid approach with IPFS references
- Allows full AC runtime + pieces
- Artist + collector-friendly metadata
AC-Native Generative Token Platform
- Build bootloader.art-like experience within AC
- Own token minting flow
- Seed-based piece rendering
- Contract integration (ERC-721)
Live Code Updates via bootloader.art
- Leverage bootloader's updatable-code feature
- Artists iterate on pieces post-mint
- Collectors' NFTs evolve over time
- Aligned with AC's dynamic philosophy

Risk Assessment #

Risk	Probability	Impact	Mitigation
Size constraints prove insurmountable	Medium	High	Fall back to IPFS approach, accept off-chain code
bootloader.art API incompatibility	Low	Medium	Early POC with their team, API documentation review
KidLisp → seed-determinism issues	Low	Medium	Extensive testing, fix any RNG non-determinism
Community disinterest (not seen as "real" AC)	Medium	Medium	Frame as expansion, not replacement; emphasize artist control
IPFS availability/centralization concerns	Low	High	Partner with Pinata, Arweave backup, own IPFS node
Gas costs for on-chain updates	Low	Low	Use L2s (Optimism, Arbitrum), or fully off-chain approach

Cost Estimation #

Task	Effort	Cost (Internal)	Notes
KidLisp bootloader shim	1-2d	Low	Reuse kidlisp-bundler.mjs
Integration testing	1-2d	Low	5-10 pieces
Documentation	1d	Low	API mappings, examples
POC deployment	2-3d	Low	bootloader.art partnership
IPFS bridge (optional)	2d	Medium	Pinata API integration
Total (Bootloader Path)	7-10d	~$2-3k	Low cost, medium effort
Full AC + IPFS approach	3-5d	Medium	Simpler, less optimization

Proof of Concept Roadmap #

Week 1: Research & Planning #

Research bootloader.art capabilities
Contact bootloader.art team for API details
Identify 3 candidate KidLisp pieces
Create detailed size budget

Week 2: Implementation #

Create KidLisp bootloader bundle target
Implement seed-based rendering
Test determinism across browsers
Create example piece adaption

Week 3: Testing & Integration #

Deploy 1-3 pieces to testnet
Gather feedback
Optimize bundle size further
Document integration process

Week 4: Go/No-Go Decision #

Evaluate technical + community reception
Decide on IPFS vs. on-chain approach
Plan full launch (if proceeding)

Conclusion #

Integration with bootloader.art is technically feasible for a KidLisp-focused, on-chain-optimized subset of AC's creative platform. Key findings:

Size Constraints Are the Core Challenge
- Full AC runtime (7-8 MB) is 300+ times too large for on-chain storage
- Ultra-minimal KidLisp bundle can reach ~20-24 KB (achievable but tight)
- IPFS off-chain approach removes size constraints, but loses "on-chain" authenticity
KidLisp Is the Right Vehicle
- Interpreter-based (smaller than JavaScript)
- Math-centric (suited to generative art)
- Already optimized in existing codebase
Three Viable Paths:
- Approach 1 (Recommended): Ultra-minimal KidLisp on-chain (~20 KB)
- Approach 2 (Easier): Full bundle on IPFS, metadata on-chain
- Approach 3 (Hybrid): Seed on-chain, code on IPFS
Community/Market Fit
- Generative tokens are hot; AC has the art
- But AC's identity is interactive, not static
- Position as "evolution of AC," not replacement
Recommended Next Step:
- Build KidLisp bootloader shim (1-2 days)
- Test with 3 pieces
- Contact bootloader.art team with POC
- Decide on long-term integration path

References #

bootloader.art — Official platform
bootloader.art Help — Documentation
Advice on Creating On-Chain Generated NFT Art — Technical constraints
How To Create Generative Art NFTs — Chainlink tutorial
Autoglyphs — Early on-chain generative art (precedent)
On-Chain Is Art Blocks — Art Blocks architecture

Report compiled: 2026-04-14
Next review: After initial bootloader.art team contact

Bootloader.art Integration Feasibility Report #

Executive Summary #

Key Finding #

What is Bootloader.art? #

Platform Overview #

Key Innovation: Living Code #

Technical Architecture #

Our Current Bundling Infrastructure #

Existing Bundlers #

1. Oven Bundler (oven/bundler.mjs) #

2. KidLisp Bundler (system/backend/kidlisp-bundler.mjs) #

On-Chain Storage Constraints #

Blockchain Size Limits #

Gas Cost Impact #

Reference: Autoglyphs Precedent #

AC Bundle Size Analysis #

Current Oven Output #

KidLisp Bundler (Optimized) #

Ultra-Minimal Bootloader Bundle Target #

Feasibility Assessment #

✅ What Works Well #

⚠️ Significant Challenges #

❌ What Doesn't Work #

Integration Approaches #

Approach 1: KidLisp-Only Ultra-Minimal (RECOMMENDED) #

Approach 2: Off-Chain Code + On-Chain Metadata #

Approach 3: Hybrid Hybrid: Small On-Chain + Large Off-Chain #

API Constraints & Integration Points #

Bootloader.art Expected Interface #

AC Piece Adaptation Required #

Missing Features in Bootloader Context #

Generative Tokens: AC Angle #

What Are Generative Tokens? #

AC's Unique Position #

Generative Token Use Cases for AC #

Recommendations #

Short Term (Feasibility Phase) #

Medium Term (Proof of Concept) #

Long Term (Ecosystem Integration) #

Risk Assessment #

Cost Estimation #

Proof of Concept Roadmap #

Week 1: Research & Planning #

Week 2: Implementation #

Week 3: Testing & Integration #

Week 4: Go/No-Go Decision #

Conclusion #

References #

1. Oven Bundler (`oven/bundler.mjs`) #

2. KidLisp Bundler (`system/backend/kidlisp-bundler.mjs`) #