+166

papers/arxiv-calarts/calarts-cards.tex

reviewed

··· 1 1 + % !TEX program = xelatex 2 2 + % Cards format — auto-generated from calarts.tex by cards-convert.mjs 3 3 + \documentclass[11pt]{article} 4 4 + 5 5 + \usepackage{fontspec} 6 6 + \usepackage{unicode-math} 7 7 + \setmainfont{Latin Modern Roman} 8 8 + \setsansfont{Latin Modern Sans} 9 9 + \setmonofont{Latin Modern Mono}[Scale=0.88] 10 10 + 11 11 + 12 12 + \usepackage{graphicx} 13 13 + \graphicspath{{figures/}{../../papers/arxiv-ac/figures/}} 14 14 + \usepackage{booktabs} 15 15 + \usepackage{tabularx} 16 16 + \usepackage{ragged2e} 17 17 + \usepackage{microtype} 18 18 + \usepackage{natbib} 19 19 + 20 20 + 21 21 + 22 22 + \makeatletter 23 23 + \def\input@path{{../}} 24 24 + \makeatother 25 25 + \usepackage{ac-paper-cards} 26 26 + 27 27 + 28 28 + \hypersetup{ 29 29 + pdftitle={CalArts, Callouts, and Papers: Art School as Operating System}, 30 30 + } 31 31 + 32 32 + \renewcommand{\acpdfbase}{calarts-callouts-papers-26-arxiv} 33 33 + \begin{document} 34 34 + 35 35 + % ============================================================ 36 36 + % TITLE CARD 37 37 + % ============================================================ 38 38 + \thispagestyle{empty} 39 39 + \vspace*{\fill} 40 40 + \begin{center} 41 41 + \includegraphics[height=9em]{pals}\par\vspace{0.1em} 42 42 + {\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} CalArts, Callouts, and Papers}\par 43 43 + \vspace{0.1em} 44 44 + {\fontsize{9pt}{11pt}\selectfont\color{acpink} Art School as Operating System}\par 45 45 + \vspace{0.4em} 46 46 + {\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par 47 47 + {\small\color{acgray} Aesthetic.Computer}\par 48 48 + {\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par 49 49 + \vspace{0.4em} 50 50 + \rule{0.5\textwidth}{0.5pt}\par 51 51 + \vspace{0.15em} 52 52 + \colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par 53 53 + \vspace{0.1em} 54 54 + {\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/894fbcb44}{894fbcb44}}\par 55 55 + \end{center} 56 56 + \vspace*{\fill} 57 57 + 58 58 + % ============================================================ 59 59 + % INDEX CARD 60 60 + % ============================================================ 61 61 + \cardindex 62 62 + 63 63 + % ============================================================ 64 64 + % BODY 65 65 + % ============================================================ 66 66 + \section{The Disney Machine} 67 67 + 68 68 + Walt Disney founded CalArts in 1961 by merging the Chouinard Art Institute and the Los Angeles Conservatory of Music. He wanted an art school that worked like his studio: all the disciplines in one building, sharing tools and ideas. Disney died before the Valencia campus opened in 1971, but the structure he demanded---no walls between departments, shared facilities, a culture of cross-disciplinary collision---shaped everything that followed. 69 69 + 70 70 + The founding vision was industrial. Disney needed animators who could draw, musicians who understood timing, actors who could improvise to a storyboard. The school was a talent pipeline for the studio~\citep{singerman1999art}. But something else happened. The faculty Disney's heirs hired---among them Allan Kaprow, Judy Chicago, John Baldessari, Miriam Schapiro, Nam June Paik---turned the interdisciplinary structure into a laboratory for postwar American art. The machine Disney built to produce animators became a machine that produced conceptual artists, feminist performance, video art, and eventually the generation that would define post-studio practice. 71 71 + 72 72 + The operating system analogy is exact. An OS does not make the software; it provides the environment in which software can run. CalArts does not make the art; it provides the conditions---spatial, social, pedagogical---in which a particular kind of artist becomes possible. Change the OS and you change what can be made. 73 73 + 74 74 + \section{Callouts} 75 75 + 76 76 + \subsection{The crit as oral tradition} 77 77 + 78 78 + The crit at CalArts is not a grade. It is a callout. Someone puts work on the wall and the room responds---not with rubrics or learning outcomes but with the unscripted, sometimes brutal, sometimes generous honesty of people who have been looking at art together for long enough to skip pleasantries. 79 79 + 80 80 + \citet{elkins2001why} argues that the crit is unteachable in the same way art is unteachable: what happens in a good crit cannot be reduced to a method. It is an oral tradition. The knowledge produced in a three-hour crit exists only in the room. It cannot be written down without becoming something else---a summary, a review, a judgment. The crit is live. It is a performance of attention~\citep{hooks1994teaching}. 81 81 + 82 82 + CalArts crits are famous for their intensity. The school's small size (roughly 1,500 students), residential campus, and interdisciplinary structure mean that a painter's crit might include a composer, an animator, a filmmaker, and a dancer. The feedback is not discipline-specific. It is \emph{perceptual}: what does this do to my body, my ear, my sense of time? The callout is not ``this is good painting.'' The callout is ``this is alive'' or ``this is dead.'' 83 83 + 84 84 + \subsection{Hallway knowledge} 85 85 + 86 86 + Most of what CalArts teaches happens outside the classroom. The hallways of the main building---a brutalist megastructure designed by Ladd \& Kelsey---function as an informal salon. A composer walks past a sculptor's open studio and hears a sound that changes both of their work. A filmmaker screens dailies at 2 AM and a dancer wanders in and starts improvising to the footage. 87 87 + 88 88 + This is not curriculum. It is \emph{architecture}. The building forces collision. The cafeteria (the only one) forces everyone into the same room. The hallways are wide enough to stop and talk. The studios are open. The practice rooms leak sound. The building is an instrument that plays the people inside it. 89 89 + 90 90 + \citet{deduve1994attitude} identifies three paradigms of art education: the academy (talent-imitation), the Bauhaus (creativity-medium-invention), and the postwar art school (attitude-practice-deconstruction). CalArts invented a fourth: \emph{proximity}. Put different disciplines close enough together and they contaminate each other. The contamination is the education. 91 91 + 92 92 + \subsection{The institutional dare} 93 93 + 94 94 + CalArts runs on dares. Not explicit ones---no one says ``I dare you.'' But the culture is organized around a challenge structure: can you make something that holds up in a room full of people who are better than you? Can you present work that survives the callout? 95 95 + 96 96 + This is different from the tech-school sprint review, where work is evaluated against user stories and acceptance criteria~\citep{vinsel2020innovation}. The CalArts dare has no criteria. There is no rubric. The question is not ``does this meet the brief?'' The question is ``does this need to exist?'' The dare is existential, not functional. 97 97 + 98 98 + The dare also operates between departments. A music student who makes a piece with video is daring the film students to pay attention. A dancer who codes an interactive installation is daring the art students to take technology seriously. The dare is the mechanism of cross-disciplinary contamination. It says: your discipline is not sufficient. Come play in mine. 99 99 + 100 100 + \section{Why Papers} 101 101 + 102 102 + \subsection{The paper as callout} 103 103 + 104 104 + This paper series---twenty papers written in three weeks---is itself a callout. It says: an artist-programmer can write theory. Not ``theory-lite,'' not ``artist statements with citations,'' but real papers with real arguments and real bibliographies that engage with real scholarship. 105 105 + 106 106 + The art world does not expect this. Artists are expected to make work and let critics write about it. The division of labor is clear: artists produce, critics explain, historians contextualize. When an artist writes theory, the institutional response is suspicion. Is it real scholarship? Is it vanity publishing? Is it art? 107 107 + 108 108 + The answer is: it does not matter. The paper is a callout. It forces the ideas to stand in the open, exposed to criticism, in a format that the academy recognizes and the art world does not control. \citet{fraser2005critique} noted that institutional critique became an institution. These papers attempt something different: not critique of the institution but \emph{use} of the institution's own format---the academic paper---as artistic material. 109 109 + 110 110 + \subsection{The paper as instrument} 111 111 + 112 112 + A paper is a technology. It has a format (sections, citations, abstract, bibliography), a distribution system (journals, preprints, repositories), and a social protocol (peer review, citation, response). Like any technology, it can be played. 113 113 + 114 114 + \ac{} treats the piece as the fundamental unit of creative cognition~\citep{scudder2026pieces}. A piece is a single file that exports lifecycle functions: \texttt{boot}, \texttt{paint}, \texttt{act}, \texttt{sim}. A paper has the same structure: it boots (abstract), paints (argument), acts (engages with prior work), and simulates (proposes consequences). The paper is a piece written in \LaTeX{} instead of JavaScript. 115 115 + 116 116 + This is not metaphor. The papers are built with the same infrastructure as the software: a CLI (\texttt{papers/cli.mjs}), incremental builds, multi-language deployment, automated publishing. The paper \emph{is} software. The argument \emph{is} the program. 117 117 + 118 118 + \subsection{The PSYCHO designation} 119 119 + 120 120 + This paper is marked PSYCHO. Not ``Working Draft,'' not ``Preprint,'' not ``Under Review.'' PSYCHO. 121 121 + 122 122 + The designation is a callout to the paper format itself. Academic papers pretend to be neutral---objective reports of findings, written in passive voice, stripped of personality. The PSYCHO label refuses this pretense. It says: this paper has a voice, it has an agenda, it has a temperature. It is not neutral. It is not trying to be. 123 123 + 124 124 + The word ``psycho'' comes from the Greek \textit{psykhe}---soul, mind, breath. A PSYCHO paper is a paper with a soul. It breathes. It has opinions that are not hedged with ``further research is needed.'' It makes claims and dares you to disagree. 125 125 + 126 126 + \section{CalArts and Aesthetic Computer} 127 127 + 128 128 + \subsection{The OS inheritance} 129 129 + 130 130 + The author attended CalArts (MFA Art, 2012). The experience is the substrate on which \ac{} is built. Not the techniques---CalArts does not teach programming---but the \emph{assumptions}: that disciplines should contaminate each other, that the medium is not the point, that the dare is more important than the deliverable, that art is a way of being in the world rather than a product to be shipped. 131 131 + 132 132 + \ac{} inherits CalArts's operating system. The piece model---one file, immediate-mode graphics, lifecycle functions---is the digital equivalent of the open studio: anyone can see what you are making, anyone can fork it, anyone can call it out. The social network is organized around \emph{paths} (memorizable URLs) rather than feeds, the same way CalArts is organized around hallways rather than algorithms. 133 133 + 134 134 + \np{}.com is the clearest CalArts inheritance. It is an instrument that anyone can play, that does not require training, that rewards exploration over expertise. The hallway encounter---stumbling onto someone else's work and being changed by it---is the design pattern. You type a URL. You land on a piece. You play it. You move on. No feed. No algorithm. No metrics. Just proximity. 135 135 + 136 136 + \subsection{The crit goes online} 137 137 + 138 138 + Publishing these papers is a crit. The room is the internet. The callout is public. The work is exposed---not to a room of fifteen people who know you but to anyone with a browser and an opinion. 139 139 + 140 140 + This is terrifying in the same way a CalArts crit is terrifying: you cannot control the response. The work either holds or it does not. The dare is the same dare: does this need to exist? 141 141 + 142 142 + \section{Against Neutrality} 143 143 + 144 144 + The academic paper pretends to be a window---transparent, letting you see the research behind it. But every window is also a frame. The paper format frames what can be said: passive voice, hedged claims, deference to prior work, the fiction of objectivity~\citep{freire1970pedagogy}. 145 145 + 146 146 + CalArts teaches the opposite. Stand behind your work. Say what you mean. If you cannot defend it in the room, it is not ready. The callout is a technology of accountability: it forces you to own your claims in front of people who will push back. 147 147 + 148 148 + These papers are written in that spirit. They have a voice. They make claims. They cite scholarship not to hide behind it but to argue with it, to build on it, to dare it to respond. The PSYCHO designation is a flag: this paper is not pretending to be neutral. It has a position. It has a temperature. It is standing in the room, waiting for the callout. 149 149 + 150 150 + \citet{spivak2012aesthetic} argues that aesthetic education trains the imagination for ethical solidarity. CalArts does this---not through curriculum but through proximity, through the dare, through the crit that forces you to see your work through someone else's eyes. These papers attempt the same thing in a different medium: to train the reader's imagination for a different kind of creative computing, one built on instruments rather than feeds, on pieces rather than products, on callouts rather than engagement metrics. 151 151 + 152 152 + \section{Conclusion} 153 153 + 154 154 + CalArts is an operating system. Its kernel is proximity. Its shell is the crit. Its process model is the dare. \ac{} runs on the same OS, ported from the physical campus to the browser to bare metal~\citep{scudder2026ac, scudder2026os}. 155 155 + 156 156 + The callout is the mechanism. The paper is the format. The PSYCHO designation is the temperature. Together they say: art can write theory, theory can be art, and neither needs permission from the institutions that claim to own them. 157 157 + 158 158 + These papers are hallway knowledge, finally written down---knowing that the writing changes them, knowing that the crit never ends, knowing that the dare is the point. 159 159 + 160 160 + \vspace{0.5em} 161 161 + \noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913} 162 162 + 163 163 + \bibliographystyle{plainnat} 164 164 + \bibliography{references} 165 165 + 166 166 + \end{document}

+347

papers/arxiv-futures/futures-cards.tex

reviewed

··· 1 1 + % !TEX program = xelatex 2 2 + % Cards format — auto-generated from futures.tex by cards-convert.mjs 3 3 + \documentclass[11pt]{article} 4 4 + 5 5 + \usepackage{fontspec} 6 6 + \usepackage{unicode-math} 7 7 + \setmainfont{Latin Modern Roman} 8 8 + \setsansfont{Latin Modern Sans} 9 9 + \setmonofont{Latin Modern Mono}[Scale=0.88] 10 10 + 11 11 + 12 12 + \usepackage{graphicx} 13 13 + \graphicspath{{figures/}{../../papers/arxiv-ac/figures/}} 14 14 + \usepackage{booktabs} 15 15 + \usepackage{tabularx} 16 16 + \usepackage{ragged2e} 17 17 + \usepackage{microtype} 18 18 + \usepackage{natbib} 19 19 + 20 20 + 21 21 + 22 22 + \makeatletter 23 23 + \def\input@path{{../}} 24 24 + \makeatother 25 25 + \usepackage{ac-paper-cards} 26 26 + 27 27 + % Extra commands from base paper 28 28 + \newcommand{\acos}{\textsc{AC Native OS}} 29 29 + 30 30 + \hypersetup{ 31 31 + pdftitle={Five Years from Now: What Aesthetic Computer Probably Becomes}, 32 32 + } 33 33 + 34 34 + \renewcommand{\acpdfbase}{five-years-from-now-26-arxiv} 35 35 + \begin{document} 36 36 + 37 37 + % ============================================================ 38 38 + % TITLE CARD 39 39 + % ============================================================ 40 40 + \thispagestyle{empty} 41 41 + \vspace*{\fill} 42 42 + \begin{center} 43 43 + \includegraphics[height=9em]{pals}\par\vspace{0.1em} 44 44 + {\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Five Years from Now}\par 45 45 + \vspace{0.1em} 46 46 + {\fontsize{9pt}{11pt}\selectfont\color{acpink} What Aesthetic Computer Probably Becomes}\par 47 47 + \vspace{0.4em} 48 48 + {\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par 49 49 + {\small\color{acgray} Aesthetic.Computer}\par 50 50 + {\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par 51 51 + \vspace{0.4em} 52 52 + \rule{0.5\textwidth}{0.5pt}\par 53 53 + \vspace{0.15em} 54 54 + \colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par 55 55 + \vspace{0.1em} 56 56 + {\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/894fbcb44}{894fbcb44}}\par 57 57 + \end{center} 58 58 + \vspace*{\fill} 59 59 + 60 60 + % ============================================================ 61 61 + % INDEX CARD 62 62 + % ============================================================ 63 63 + \cardindex 64 64 + 65 65 + % ============================================================ 66 66 + % BODY 67 67 + % ============================================================ 68 68 + \section{Introduction} 69 69 + 70 70 + \ac{} is a mobile-first runtime and social network for creative computing, comprising 359 built-in interactive programs (``pieces''), a bare-metal Linux operating system that boots any x86\_64 machine into a creative instrument, a minimal Lisp dialect for generative art, and a growing community of 2,812 registered users~\citep{scudder2026ac}. The project is authored and maintained primarily by a single developer, @jeffrey, with AI-assisted maintenance (``AestheticAnts'') handling routine upkeep. 71 71 + 72 72 + As of March 2026, the project has produced 19 research papers across four languages, a bare-metal OS that boots in 7.3 seconds~\citep{scudder2026os}, a blockchain integration for minting generative artworks, and a 7,912-line musical instrument (\np{}) that has become the system's front door~\citep{scudder2026notepat}. The codebase traces its lineage through 94 predecessor projects spanning more than a decade of tool-making. 73 73 + 74 74 + This paper does not propose what \ac{} \emph{should} do. It attempts to read what it \emph{probably will} do, based on the momentum already visible in the code, the papers, the infrastructure decisions, and the philosophical commitments that have shaped the project to date. 75 75 + 76 76 + % ============ 2. NINETY-FOUR PROJECTS ============ 77 77 + 78 78 + \section{Ninety-Four Projects and Counting} 79 79 + \label{sec:history} 80 80 + 81 81 + Any projection of \ac{}'s future must reckon with the depth of its past. The project is not a startup pivoting toward product-market fit. It is the 95th iteration of a single sustained inquiry: \emph{what should a personal creative computing instrument be?} 82 82 + 83 83 + \subsection{The Drawing Software Lineage (2011--2020)} 84 84 + 85 85 + The archaeology paper~\citep{scudder2026archaeology} traces \ac{} through 94 predecessor projects spanning two GitHub accounts (50+ repositories), a 109\,GB legacy server archive, and a Dropbox corpus. The trajectory begins with \textbf{thePRBAT} (Polygon Replicating Bitmap Authoring Tool, 2011), a Flash-based digital imaging tool built as a BFA thesis at Ringling College, and arrives at \ac{} through a decade of drawing software variants: \textbf{JeffreyPaint} (2014, JavaScript + Unity), \textbf{Finger Quilt} (2016, iOS/Swift), \textbf{Dot} (2017, a plotting application that prefigures AC's \texttt{plot} disk), and most importantly \textbf{No Paint} (2014--2020), which went through five incarnations---Rails, JavaScript shim, WebGL prototype, iOS/Cordova, Vercel site---before being absorbed into \ac{}. 86 86 + 87 87 + This is not a history of abandoned projects. It is a history of \emph{restarts}: the same person, asking the same question, choosing to start over rather than accumulate features. The pattern is visible in \ac{} itself: the piece model (single file, lifecycle functions, immediate-mode graphics) is a constraint-first design that \emph{prevents} the feature accumulation that killed earlier iterations. 88 88 + 89 89 + \subsection{The Performance Turn (2016--2018)} 90 90 + 91 91 + Between 2016 and 2018, @jeffrey toured with Goodiepal \& Pals across 65+ venues in Europe, building real-time performance tools: audience participation interfaces, music notation renderers, subtitle displays for live lectures. These tools---built fast, used once, thrown away---established a design principle that persists in \ac{}: software as instrument, not as product. The tools were played, not shipped. 92 92 + 93 93 + The Goodiepal influence runs deeper than collaboration. The goodiepal paper~\citep{scudder2026goodiepal} identifies five threads that carry through to \ac{}: instrument-first design, community organized through affinity rather than institution, works designed to resist digital reproduction, and radical pedagogy through direct engagement rather than curriculum. 94 94 + 95 95 + \subsection{Why History Matters for Projection} 96 96 + 97 97 + The 94-project history constrains our projection in two ways. First, it makes sudden pivots unlikely. @jeffrey has been circling the same problems---personal tools, creative instruments, constraint-based design---for 15 years. The next 5 years will almost certainly stay within this orbit. Second, it makes abandonment unlikely for the reasons people usually abandon projects (boredom, loss of interest, attraction to something shinier). The risk is not distraction; it is exhaustion. We return to this in \S\ref{sec:giveup}. 98 98 + 99 99 + % ============ 3. THE SURPLUS HARDWARE WAVE ============ 100 100 + 101 101 + \section{The Surplus Hardware Wave} 102 102 + \label{sec:surplus} 103 103 + 104 104 + The single largest force acting on \ac{}'s future is external: in October 2025, Microsoft ended support for Windows 10, rendering an estimated 240 million PCs obsolete by institutional standards~\citep{ewaste2024monitor}. These machines are not broken. They are ThinkPads, EliteBooks, and Latitudes with 8--16\,GB RAM, 1080p screens, WiFi, and 6--10 hour batteries. They cost \$30--80 on the surplus market. They are the raw material for everything that follows. 105 105 + 106 106 + \subsection{From Prototype to Fleet (2026--2027)} 107 107 + 108 108 + \acos{} already boots on surplus hardware~\citep{scudder2026os}. The gap between ``boots on two ThinkPads in @jeffrey's apartment'' and ``boots on 30 machines in a classroom'' is not primarily technical. It is operational: WiFi credential management, per-device identity provisioning, hardware compatibility testing across dozens of laptop models, and a flashing workflow that a non-technical person can execute. 109 109 + 110 110 + The likely near-term work is mundane but critical: 111 111 + 112 112 + \begin{itemize} 113 113 + \item \textbf{Per-user WiFi storage}: moving hardcoded SSIDs out of JavaScript pieces into persistent per-device config files that survive OTA updates 114 114 + \item \textbf{Hardware compatibility matrix}: systematic testing across ThinkPad X1/T/L series, HP EliteBook 800 series, Dell Latitude 5000/7000 series 115 115 + \item \textbf{One-command flashing}: a USB image builder that takes a handle, colors, and WiFi credentials and produces a bootable drive 116 116 + \item \textbf{A/B kernel slots}: dual-partition boot with automatic rollback if the new kernel fails health checks 117 117 + \end{itemize} 118 118 + 119 119 + These are not glamorous features. They are the difference between an art project and an infrastructure project. The trajectory of the codebase---OTA updates already working, build names already generated, device identity already inscribed in the boot partition---suggests that @jeffrey understands this distinction and is moving toward the infrastructure side. 120 120 + 121 121 + \subsection{The 50-Dollar Instrument (2027--2028)} 122 122 + 123 123 + If the operational work lands, the economic argument becomes very loud: a complete creative computing instrument---personalized, self-updating, requiring zero IT infrastructure---for the price of a surplus laptop and a USB drive. No Chromebook enrollment. No Apple ID. No subscription. 124 124 + 125 125 + The OLPC project~\citep{kraemer2009olpc} demonstrated that hardware-first approaches to computing access fail on cost and logistics. The Raspberry Pi addressed cost (\$35) but requires \$150 in accessories. \ac{}'s proposition is different: the hardware already exists, already has a screen, keyboard, battery, and WiFi, and is being discarded by the millions. The software is 89\,MB. 126 126 + 127 127 + The likely outcome by 2028 is not mass adoption but \emph{proof points}: a handful of classrooms, community centers, or workshop contexts where fleets of 10--30 surplus machines run \acos{} and the results are documented. These proof points become the evidence base for grant applications, institutional partnerships, and the sustainability arguments described in \S\ref{sec:sustainability}. 128 128 + 129 129 + % ============ 3. PLANETARY ENSEMBLES ============ 130 130 + 131 131 + \section{Planetary Ensembles} 132 132 + \label{sec:ensembles} 133 133 + 134 134 + The PLOrk paper~\citep{scudder2026plork} makes an argument that the existing codebase already supports: laptop orchestras have been musically legitimate since Princeton's PLOrk proved the concept in 2006~\citep{trueman2006plork}, but the model is trapped in universities at \$1,500+ per seat. \acos{} on surplus hardware reduces the cost to \$50/seat. The question is whether anyone will play. 135 135 + 136 136 + \subsection{notepat as Ensemble Instrument (2026--2027)} 137 137 + 138 138 + \np{} is already a polyphonic keyboard instrument with 32-voice synthesis, room reverb, and wave-type selection~\citep{scudder2026notepat}. It runs on bare metal at 192\,kHz. The missing ingredient for ensemble performance is not audio quality but \emph{coordination}: synchronized tempo, shared harmonic space, and a conductor interface. 139 139 + 140 140 + The likely development path: 141 141 + 142 142 + \begin{itemize} 143 143 + \item \textbf{UDP ensemble sync}: extending the existing dual-channel networking (WebSocket + UDP) to synchronize beat clocks across devices on a local network 144 144 + \item \textbf{Conductor piece}: a new piece that displays the ensemble state and allows a conductor to set tempo, key, and dynamics 145 145 + \item \textbf{Spatialization}: using the physical positions of surplus laptops as distributed speakers---the ensemble \emph{is} the sound system, following Turino's participatory music model~\citep{turino2008music} 146 146 + \end{itemize} 147 147 + 148 148 + This thread has obvious conference appeal. A live demonstration of 10 surplus ThinkPads playing a coordinated musical piece---each showing the player's handle in rainbow text, each contributing a voice to a distributed sound field---is the kind of demo that wins Ars Electronica mentions and NIME submissions. 149 149 + 150 150 + \subsection{Beyond Music (2028--2031)} 151 151 + 152 152 + The ensemble model generalizes beyond music. A network of surplus machines running coordinated pieces could be: 153 153 + 154 154 + \begin{itemize} 155 155 + \item A \textbf{distributed drawing wall}: each screen shows a section of a larger canvas, participants draw locally, and the network composites the result 156 156 + \item A \textbf{collaborative KidLisp environment}: students write generative programs that feed into a shared visual space 157 157 + \item A \textbf{performance score}: the machines execute a graphic score~\citep{scudder2026pieces}, each interpreting the same notation through different pieces 158 158 + \end{itemize} 159 159 + 160 160 + The infrastructure for all of these already exists: WebSocket relay, UDP broadcast, per-device identity, and a piece model that supports any combination of graphics, audio, and input. What's missing is the \emph{choreography}---the pieces themselves and the social forms around them. 161 161 + 162 162 + % ============ THE THIRD DIMENSION ============ 163 163 + 164 164 + \section{The Third Dimension} 165 165 + \label{sec:3d} 166 166 + 167 167 + \ac{} is widely perceived as a 2D system. The immediate-mode graphics API---\texttt{wipe}, \texttt{ink}, \texttt{line}, \texttt{box}---and the pixel-art aesthetic of most pieces reinforce this impression. But the infrastructure tells a different story. A full software 3D rasterizer already exists, a multiplayer FPS already ships, and the architectural choices made in the bare-metal OS position 3D as the next major expressive frontier. 168 168 + 169 169 + \subsection{What Already Works} 170 170 + 171 171 + The bare-metal OS includes \texttt{graph3d.c}, a ~600-line CPU software rasterizer with perspective projection, frustum clipping (Sutherland-Hodgman against 6 clip planes), depth buffering, per-vertex color interpolation, and texture mapping with perspective-correct barycentric coordinates. The JavaScript API exposes this through a \texttt{Form} constructor: pieces create meshes with vertex positions, colors, and texture coordinates, then render them with \texttt{ink(r,g,b).form(mesh)}. 172 172 + 173 173 + Two production pieces demonstrate the system. \texttt{fps.mjs} provides a first-person camera with pointer lock, WASD movement, textured ground planes, and rotating cubes. \texttt{1v1.mjs} extends this into a multiplayer FPS with hitscan weapons, bot AI (patrol/chase/flee states), kill tracking, and the dual-channel networking pattern (WebSocket for reliable game events, UDP for low-latency position sync). The browser path uses Three.js (r0.182) with WebGL rendering and includes VR/XR session support~\citep{sutherland1968head}. 174 174 + 175 175 + The system thus has two parallel 3D paths: a software rasterizer on bare metal (CPU-only, no GPU) and a hardware-accelerated path in the browser (WebGL/Three.js, with WebGPU infrastructure in place). The API surface is identical from the piece author's perspective. 176 176 + 177 177 + \subsection{The GPU Question on Bare Metal (2026--2028)} 178 178 + 179 179 + The software rasterizer is elegant but fundamentally limited. Every surplus ThinkPad and EliteBook in the target fleet has an Intel integrated GPU capable of OpenGL 4.x or Vulkan 1.x, sitting idle. The kernel's DRM subsystem already manages the display via KMS modesetting; extending it to expose a render node for GPU-accelerated rasterization is a known engineering path (EGL on DRM, or Vulkan via \texttt{/dev/dri/renderD128}). 180 180 + 181 181 + The likely trajectory is cautious. @jeffrey's design instinct favors software control over hardware delegation---the entire bare-metal OS philosophy is ``know every instruction between power-on and pixel.'' GPU drivers introduce opacity: firmware blobs, driver bugs, vendor-specific behavior. The software rasterizer's virtue is that it is \emph{legible}: the pipeline from vertex to pixel is 600 lines of C that a student can read. 182 182 + 183 183 + The probable compromise: GPU acceleration as an opt-in path for pieces that need it, with the software rasterizer remaining the default and the reference implementation. This mirrors the browser architecture, where WebGPU exists alongside the 2D canvas but doesn't replace it. 184 184 + 185 185 + \subsection{3D as Creative Medium (2028--2031)} 186 186 + 187 187 + The more interesting question is not technical but expressive. What does 3D mean in a system designed around constraint, immediacy, and single-file pieces? 188 188 + 189 189 + The predecessor projects offer a clue. @jeffrey's work has always been about \emph{painting}: No Paint, JeffreyPaint, thePRBAT, the Radical Digital Painting lecture tour. The 3D infrastructure is not building toward a game engine or a CAD tool. It is building toward \emph{spatial painting}---the ability to place marks, colors, and forms in three-dimensional space with the same immediacy that \texttt{ink(255,0,0).line(0,0,100,100)} provides in two dimensions. 190 190 + 191 191 + The pieces that will matter are not the ones that look like Unity demos. They are the ones where 3D is used the way @jeffrey uses 2D: as raw material for instruments, for performances, for things that are played rather than consumed. A 3D \np{} where notes have spatial position and the room reverb is literal---sound emanating from forms distributed in virtual space. A 3D KidLisp where \texttt{(box 0 0 0 50 50 50)} places a cube the way \texttt{(rect 0 0 50 50)} places a rectangle. A fleet of surplus laptops each rendering a different camera angle of the same distributed 3D scene. 192 192 + 193 193 + The convergence with ensembles (\S\ref{sec:ensembles}) is where 3D becomes genuinely new. Synchronized 3D scenes across networked surplus machines---each screen a window into a shared virtual space, each player's input affecting the scene for all participants---is a form that neither game engines nor creative coding tools have explored at the \$50/seat price point. The networking is already proven (\texttt{1v1.mjs}). The hardware is already available (\S\ref{sec:surplus}). The missing piece is the artistic vision for what a distributed spatial instrument should feel like, and that is precisely the kind of question @jeffrey has spent 94 projects learning how to answer. 194 194 + 195 195 + % ============ 5. THE SCHOLARLY TURN ============ 196 196 + 197 197 + \section{The Scholarly Turn} 198 198 + \label{sec:scholarly} 199 199 + 200 200 + Between March 3 and March 20, 2026, @jeffrey produced 19 research papers in four languages. This is not normal behavior for a solo developer. It signals a deliberate turn toward scholarly legitimacy---an attempt to build what the RESEARCH-DIRECTION.md file calls a ``research moat'' around the project. 201 201 + 202 202 + \subsection{The Paper Mill (2026--2027)} 203 203 + 204 204 + The paper infrastructure is already industrial: a custom \LaTeX{} template with AC fonts, automated PDF building via a server (``the oven''), a cards format for single-sheet printouts, and a translation pipeline producing Danish, Spanish, and Chinese editions of every paper. The 40+ readings library provides the citation base. The pipeline is designed to produce, not to prototype. 205 205 + 206 206 + The near-term trajectory is submission: ACM C\&C Demos (April 16), ICCC Short Papers (April 24), JOSS software papers (rolling). If any of these land, the project gains a scholarly foothold that most creative coding tools never achieve. Processing~\citep{reas2007processing} and Scratch~\citep{resnick2009scratch} built their academic legitimacy over years; @jeffrey is attempting to compress that timeline by producing volume and targeting multiple venues simultaneously. 207 207 + 208 208 + \subsection{Artist-Scholar Identity (2028--2031)} 209 209 + 210 210 + The CalArts paper argues that an art school is an operating system---that the structures of proximity, critique, and disciplinary contamination that characterize institutions like CalArts can be ported into software. If @jeffrey continues to publish at this rate, the papers themselves become a body of work: not documentation of a software project, but a sustained argument about what creative computing is and who it is for. 211 211 + 212 212 + The likely 5-year outcome is one of two scenarios: 213 213 + 214 214 + \begin{enumerate} 215 215 + \item \textbf{The moat holds}: 6--10 papers are published across peer-reviewed venues, @jeffrey is invited to speak at conferences, and \ac{} enters the canon alongside Processing, Scratch, and Sonic Pi~\citep{aaron2016sonic} as a recognized creative computing environment. The papers create a feedback loop: scholarly attention brings users, users create pieces, pieces generate new papers. 216 216 + \item \textbf{The moat doesn't hold}: submissions are rejected, the solo-author pattern raises reviewer eyebrows, and the paper infrastructure goes dormant. The code survives; the scholarly identity does not. This is the more common outcome for artist-programmers. 217 217 + \end{enumerate} 218 218 + 219 219 + The honest bet is somewhere between: a few publications land, enough to establish credibility in niche venues (NIME, xCoAx, ICLC), but the mainstream HCI and PL conferences remain out of reach without collaborators and user studies. 220 220 + 221 221 + % ============ 5. KIDLISP'S OWN LIFE ============ 222 222 + 223 223 + \section{KidLisp's Own Life} 224 224 + \label{sec:kidlisp} 225 225 + 226 226 + KidLisp is a 118-function Lisp dialect for generative art~\citep{scudder2026kidlisp}. It is sandboxed (no file I/O, no networking), runs in the browser, and has already accumulated 16,779 stored programs and a blockchain minting integration via Tezos. The language is small enough to fit on an index card. 227 227 + 228 228 + \subsection{Language Community (2026--2028)} 229 229 + 230 230 + The Tezos ``keeps'' system---where KidLisp programs are minted as on-chain artworks for 2.5 XTZ---creates an economic incentive to write KidLisp. The keeps contract (v11) is live, the minting UI exists at keeps.kidlisp.com, and 5 tokens have already been minted and migrated. If the generative art market remains active, this thread sustains itself. 231 231 + 232 232 + The more interesting possibility is pedagogical. KidLisp's constraints---no state mutation, no side effects beyond drawing, 118 functions, runs in a browser---make it a candidate for teaching environments. A KidLisp curriculum built around the cards format (single-sheet programs that students can hold in their hands) aligns with Papert's constructionism~\citep{papert1980mindstorms} and the project's existing infrastructure. 233 233 + 234 234 + \subsection{Language Evolution (2028--2031)} 235 235 + 236 236 + KidLisp will face pressure to grow. Users will want state, animation, interactivity, sound. The design question is whether the language absorbs these features (becoming a general-purpose creative language) or remains deliberately minimal (a ``haiku language'' for static generative art, with JavaScript handling everything else). 237 237 + 238 238 + The project's history suggests the latter. @jeffrey's design instinct, visible across 94 predecessor projects, favors sharp constraints over feature accumulation. The piece model itself---single file, lifecycle functions, immediate-mode graphics~\citep{scudder2026pieces}---is a constraint-first design. KidLisp will probably stay small. The interesting growth will be in what people make with it, not what the language adds. 239 239 + 240 240 + % ============ 6. SUSTAINABILITY ============ 241 241 + 242 242 + \section{The Sustainability Question} 243 243 + \label{sec:sustainability} 244 244 + 245 245 + Every thread described above depends on a single person continuing to work. \ac{} has no venture funding, no institutional backing, and no employees beyond @jeffrey. The AestheticAnts maintenance system automates routine tasks, but architectural decisions, paper writing, hardware testing, and community cultivation require human attention. 246 246 + 247 247 + \subsection{The Funding Landscape (2026--2028)} 248 248 + 249 249 + The project has identified funding sources: Creative Capital (\$50,000 project grants), Prix Ars Electronica (\texteuro10,000), Gary Marsden Travel Awards, and GitHub Sponsors. The paper mill is partly a grant-writing strategy: a project with 19 papers, conference demos, and a documented user base is a stronger applicant than one with only code. 250 250 + 251 251 + The Tezos keeps provide a small revenue stream. Prints (20 ordered as of March 2026) provide another. Neither is sufficient to sustain full-time development. 252 252 + 253 253 + The honest projection: by 2028, the project either secures a grant or institutional affiliation (a residency, a teaching position, a research fellowship) or it slows to maintenance-mode development. This is not a failure scenario---many important creative tools are maintained part-time by their creators for decades. But the ambitious threads (planetary ensembles, surplus hardware fleets, scholarly moat) require full-time attention. 254 254 + 255 255 + \subsection{The Solo-Author Risk (2028--2031)} 256 256 + 257 257 + Illich's ``tools for conviviality''~\citep{illich1973tools} argues that good tools should be operable without specialized expertise. \ac{} aspires to this for its users, but the project itself is not convivial in Illich's sense: it requires @jeffrey's expertise to maintain. The bus factor is one. 258 258 + 259 259 + The mitigation is already partially in place: the codebase is open source, the architecture is documented in 19 papers, the piece API is designed for single-file simplicity, and the AestheticAnts system handles routine maintenance autonomously. But the difference between ``the code is open'' and ``someone else can lead the project'' is vast. 260 260 + 261 261 + The likely 5-year trajectory: @jeffrey remains the sole architect. A small community of piece authors contributes content (265 published pieces and growing). One or two contributors submit pull requests for specific features. The project does not achieve the ``thousand contributors'' model of Processing or p5.js, but it doesn't need to---its value proposition is not breadth but depth: a single vision, rigorously maintained, that takes creative computing to places committee-designed tools cannot go. 262 262 + 263 263 + % ============ 7. THE CONVERGENCE ============ 264 264 + 265 265 + \section{The Convergence} 266 266 + \label{sec:convergence} 267 267 + 268 268 + The seven threads described above are not parallel tracks. They converge. 269 269 + 270 270 + The 94-project history (\S\ref{sec:history}) establishes the trajectory that makes the other threads legible. Surplus hardware (\S\ref{sec:surplus}) provides the material base for planetary ensembles (\S\ref{sec:ensembles}). The 3D infrastructure (\S\ref{sec:3d}) extends the ensemble model into spatial performance. The papers (\S\ref{sec:scholarly}) document and legitimize all of it. KidLisp (\S\ref{sec:kidlisp}) provides a safe entry point for new users who arrive through any of these channels. Sustainability (\S\ref{sec:sustainability}) determines whether the convergence happens at all---and \S\ref{sec:giveup} examines what happens if it doesn't. 271 271 + 272 272 + The most likely 5-year scenario is this: by 2031, \ac{} is a recognized but niche creative computing environment with: 273 273 + 274 274 + \begin{itemize} 275 275 + \item \textbf{5,000--10,000 registered users}, up from 2,812, driven by notepat virality, conference demos, and classroom deployments 276 276 + \item \textbf{A bare-metal OS} deployed on 100--500 surplus machines across 5--15 sites (schools, community centers, artist residencies, workshops) 277 277 + \item \textbf{3--5 published papers} in peer-reviewed venues, establishing a minimal scholarly footprint 278 278 + \item \textbf{50,000+ KidLisp programs}, with a small but active generative art community minting keeps on Tezos 279 279 + \item \textbf{Ensemble performances} at 2--3 festivals or conferences, using fleets of surplus laptops as distributed instruments 280 280 + \item \textbf{A single maintainer} still writing most of the code, with AI-assisted maintenance handling an increasing share of routine work 281 281 + \end{itemize} 282 282 + 283 283 + This is not the most ambitious outcome, nor the most conservative. It is the outcome consistent with a project that has made specific, deliberate choices about what it cares about---depth over breadth, instruments over IDEs, maintenance over disruption---and that has the infrastructure to follow through on those choices at the pace a solo developer can sustain. 284 284 + 285 285 + % ============ 8. WHAT COULD CHANGE EVERYTHING ============ 286 286 + 287 287 + \section{What Could Change Everything} 288 288 + \label{sec:wildcards} 289 289 + 290 290 + Projections based on momentum are reliable precisely because they ignore discontinuities. Four wildcards could alter the trajectory entirely: 291 291 + 292 292 + \subsection{An Institutional Home} 293 293 + 294 294 + If @jeffrey takes a teaching position at an art school or research university, \ac{} gains something it currently lacks: students. A cohort of 15--30 students using \ac{} as their primary creative computing environment for a semester would produce more pieces, more bug reports, more use cases, and more scholarship than a decade of solo development. The CalArts paper's argument---that art school is an operating system---works in reverse: the operating system could become a school. 295 295 + 296 296 + \subsection{A Viral Moment} 297 297 + 298 298 + \np{} was posted to Hacker News and received attention. A second viral moment---a TikTok of a classroom full of surplus laptops playing music together, a tweet thread about the \$50 creative instrument, a conference demo that gets filmed and shared---could bring thousands of users in a week. The infrastructure (URL-addressable pieces, instant registration, social features) is designed to absorb this. Whether @jeffrey \emph{wants} to absorb it is a separate question. The project's anti-platform stance~\citep{fisher2009capitalist} suggests ambivalence about growth-for-growth's-sake. 299 299 + 300 300 + \subsection{AI as Collaborator} 301 301 + 302 302 + The AestheticAnts system already uses AI for routine maintenance. The agent memory system logs interactions and maintains continuity across conversations. If AI capabilities continue to advance, a future version of this system could do more than maintenance: it could write pieces, generate KidLisp programs, compose ensemble scores, and draft papers. The solo-author risk (\S\ref{sec:sustainability}) diminishes if the ``solo author'' is augmented by an AI collaborator that understands the project's history, philosophy, and codebase. 303 303 + 304 304 + This is not speculative in the way the other scenarios are. It is already happening. The question is one of degree: by 2031, does AI handle 10\% of the creative work, or 50\%? The answer will depend on choices @jeffrey makes about what he delegates and what he insists on doing himself. The project's emphasis on personal voice, on the ``PSYCHO'' papers that bear the author's temperature, suggests that the most important work will remain human. The infrastructure around it may not. 305 305 + 306 306 + \subsection{What If He Stops} 307 307 + \label{sec:giveup} 308 308 + 309 309 + The projections above assume continued effort. But the 94-project history (\S\ref{sec:history}) contains a pattern that must be named: @jeffrey has walked away from things before. No Paint had five incarnations. Each one was abandoned, not because the idea failed, but because the implementation calcified---because the gap between what the tool \emph{was} and what it \emph{should be} grew intolerable. The restarts were not failures of commitment. They were expressions of it. 310 310 + 311 311 + The risk for \ac{} is not that @jeffrey loses interest. Fifteen years of circling the same problems rules out casual abandonment. The risk is \emph{structural exhaustion}: the accumulation of operational weight---server bills, user support, hardware testing, paper submissions, grant applications, dependency updates---until the maintenance load crowds out the creative work that makes the project worth maintaining. Ukeles~\citep{ukeles1969manifesto} argued that maintenance is art, but even Ukeles acknowledged that maintenance without recognition becomes invisible labor. 312 312 + 313 313 + Three scenarios for cessation deserve consideration: 314 314 + 315 315 + \begin{enumerate} 316 316 + \item \textbf{The quiet fade}: development slows to sporadic commits, the servers stay up but the community drifts, and \ac{} joins the long list of ambitious personal tools that exist as archives rather than living systems. This is the most common outcome for solo-authored creative computing projects. It is not dramatic. It is the default. 317 317 + 318 318 + \item \textbf{The deliberate stop}: @jeffrey declares the project complete at some natural boundary---perhaps when the OS boots reliably on a dozen laptop models, or when the paper count reaches a round number, or when the 100th piece is published by someone other than him. He returns to painting on canvas (the Venice Family Clinic exhibition in May 2026 suggests this thread is already active). The code remains open. Someone may fork it. Most likely, no one does. 319 319 + 320 320 + \item \textbf{The 95th restart}: @jeffrey walks away from \ac{} to build its successor. This is the pattern the history predicts most strongly. No Paint became \ac{}. \ac{} could become something else---something that absorbs the lessons of the OS, the piece model, the ensemble networking, and the 3D rasterizer, but sheds the accumulated infrastructure weight. The new project starts clean, in a single file, and the cycle begins again. From the outside, this looks like failure. From inside the 94-project lineage, it looks like the process working exactly as designed. 321 321 + \end{enumerate} 322 322 + 323 323 + The honest assessment: scenario 3 is unlikely within 5 years because \ac{} has achieved escape velocity in ways No Paint never did---a registered user base, a bare-metal OS, a blockchain integration, 19 papers, a language with 16,000+ programs. The sunk cost is too high for a clean restart. But scenario 1 is entirely possible if the sustainability question (\S\ref{sec:sustainability}) goes unanswered. A project this ambitious, maintained by one person without stable funding, is always one bad year away from the quiet fade. 324 324 + 325 325 + The mitigation is the same one that has sustained the project so far: making the work itself rewarding enough that the operational burden is tolerable. The papers, the performances, the 3D rasterizer written from scratch, the bare-metal boot that takes 7 seconds---these are not features on a roadmap. They are the creative practice. If the practice stops being interesting, the project stops. If it stays interesting, the project survives anything short of the lights going out. 326 326 + 327 327 + % ============ 10. CONCLUSION ============ 328 328 + 329 329 + \section{Conclusion} 330 330 + 331 331 + Aesthetic Computer is a project that knows what it is. It is not searching for product-market fit, pivoting toward enterprise, or optimizing for growth metrics. It is a personal creative computing instrument being built in public by a single person who has been making versions of it for more than a decade across 94 predecessor projects. 332 332 + 333 333 + The next five years will be shaped by forces both internal (the pace @jeffrey can sustain, the funding he can secure) and external (240 million surplus PCs, the generative art economy, the academic conference cycle). The project's infrastructure---bare-metal OS, paper mill, piece model, social network, blockchain minting---is built to absorb these forces. Whether it will is a question of stamina, luck, and the willingness of the world to care about creative computing tools that are not owned by a platform. 334 334 + 335 335 + Nelson wrote in 1974 that ``you can and must understand computers NOW''~\citep{nelson1974computerlib}. Illich wrote in 1973 that tools should expand personal autonomy, not require institutional mediation~\citep{illich1973tools}. Ukeles wrote in 1969 that maintenance is art~\citep{ukeles1969manifesto}. \ac{} is the synthesis: a tool that is personal, convivial, and maintained as a creative practice. The bet is that this synthesis, applied to surplus hardware and sustained over time, creates something that lasts. 336 336 + 337 337 + Whether it does is the only interesting question. This paper offers no answer, only a reading of the forces in play. The code will decide. 338 338 + 339 339 + \vspace{0.5em} 340 340 + \noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913} 341 341 + 342 342 + % ============ REFERENCES ============ 343 343 + 344 344 + \bibliographystyle{plainnat} 345 345 + \bibliography{references} 346 346 + 347 347 + \end{document}

+491

papers/arxiv-identity/identity-cards.tex

reviewed

··· 1 1 + % !TEX program = xelatex 2 2 + % Cards format — auto-generated from identity.tex by cards-convert.mjs 3 3 + \documentclass[11pt]{article} 4 4 + 5 5 + \usepackage{fontspec} 6 6 + \usepackage{unicode-math} 7 7 + \setmainfont{Latin Modern Roman} 8 8 + \setsansfont{Latin Modern Sans} 9 9 + \setmonofont{Latin Modern Mono}[Scale=0.88] 10 10 + 11 11 + 12 12 + \usepackage{graphicx} 13 13 + \graphicspath{{figures/}{../../papers/arxiv-ac/figures/}} 14 14 + \usepackage{booktabs} 15 15 + \usepackage{tabularx} 16 16 + \usepackage{ragged2e} 17 17 + \usepackage{microtype} 18 18 + \usepackage{natbib} 19 19 + \usepackage{listings} 20 20 + 21 21 + \lstdefinelanguage{acjs}{ 22 22 + morekeywords=[1]{function,export,const,let,var,return,if,else,new,async,await,import,from}, 23 23 + morekeywords=[2]{wipe,ink,line,box,circle,write,screen,params,colon,jump,send,store,net,sound,speaker,system}, 24 24 + sensitive=true, 25 25 + morecomment=[l]{//}, 26 26 + morestring=[b]", 27 27 + morestring=[b]', 28 28 + morestring=[b]`, 29 29 + escapeinside={|}{|}, 30 30 + } 31 31 + \lstdefinestyle{acjsstyle}{ 32 32 + language=acjs, 33 33 + keywordstyle=[1]\color{jskw}\bfseries, 34 34 + keywordstyle=[2]\color{jsfn}\bfseries, 35 35 + commentstyle=\color{jscmt}\itshape, 36 36 + stringstyle=\color{jsstr}, 37 37 + } 38 38 + \lstset{ 39 39 + basicstyle=\ttfamily\small, 40 40 + breaklines=true, 41 41 + frame=single, 42 42 + rulecolor=\color{acgray!30}, 43 43 + backgroundcolor=\color{acgray!5}, 44 44 + xleftmargin=0.5em, 45 45 + xrightmargin=0.5em, 46 46 + aboveskip=0.5em, 47 47 + belowskip=0.5em, 48 48 + } 49 49 + 50 50 + \makeatletter 51 51 + \def\input@path{{../}} 52 52 + \makeatother 53 53 + \usepackage{ac-paper-cards} 54 54 + 55 55 + % Extra commands from base paper 56 56 + \newcommand{\atproto}{\textsc{AT Protocol}} 57 57 + \definecolor{jskw}{RGB}{119,51,170} 58 58 + \definecolor{jsfn}{RGB}{0,136,170} 59 59 + \definecolor{jsstr}{RGB}{170,120,0} 60 60 + \definecolor{jsnum}{RGB}{204,0,102} 61 61 + \definecolor{jscmt}{RGB}{102,102,102} 62 62 + 63 63 + \hypersetup{ 64 64 + pdftitle={Handle Identity on the AT Protocol: From Auth0 to Decentralized Sign-In}, 65 65 + } 66 66 + 67 67 + \renewcommand{\acpdfbase}{handle-identity-atproto-26-arxiv} 68 68 + \begin{document} 69 69 + 70 70 + % ============================================================ 71 71 + % TITLE CARD 72 72 + % ============================================================ 73 73 + \thispagestyle{empty} 74 74 + \vspace*{\fill} 75 75 + \begin{center} 76 76 + \includegraphics[height=9em]{pals}\par\vspace{0.1em} 77 77 + {\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Handle Identity on the AT Protocol}\par 78 78 + \vspace{0.1em} 79 79 + {\fontsize{9pt}{11pt}\selectfont\color{acpink} From Auth0 to Decentralized Sign-In on Aesthetic Computer}\par 80 80 + \vspace{0.4em} 81 81 + {\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par 82 82 + {\small\color{acgray} Aesthetic.Computer}\par 83 83 + {\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par 84 84 + \vspace{0.4em} 85 85 + \rule{0.5\textwidth}{0.5pt}\par 86 86 + \vspace{0.15em} 87 87 + \colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par 88 88 + \vspace{0.1em} 89 89 + {\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/894fbcb44}{894fbcb44}}\par 90 90 + \end{center} 91 91 + \vspace*{\fill} 92 92 + 93 93 + % ============================================================ 94 94 + % INDEX CARD 95 95 + % ============================================================ 96 96 + \cardindex 97 97 + 98 98 + % ============================================================ 99 99 + % BODY 100 100 + % ============================================================ 101 101 + \section{Introduction} 102 102 + 103 103 + Identity on the web is a landlord problem. You do not own your handle on Twitter, your username on Instagram, or your login on any platform that can delete your account. The AT Protocol~\citep{atproto2024spec}---the decentralized social networking protocol behind Bluesky---proposes a different arrangement: your identity is a cryptographic key pair, your handle is a domain name you control, and your data lives on a Personal Data Server that you can move between providers. 104 104 + 105 105 + Aesthetic Computer has operated a hybrid identity system since 2024. Auth0~\citep{auth0spa} handles authentication: OAuth 2.0 with PKCE, refresh tokens, and a managed user database. Separately, a self-hosted PDS at \texttt{at.aesthetic.computer} mints ATProto identities for every verified user. The result is a doubled system: two identities per user, two credential stores, two handle sync paths, and a paid Auth0 subscription bridging the gap. 106 106 + 107 107 + This paper asks: what if the PDS \emph{is} the identity provider? 108 108 + 109 109 + The answer is not hypothetical. pckt.blog~\citep{pcktblog2025}, a blogging platform built on the \atproto{}, authenticates users entirely through \atproto{} OAuth. Users sign in with their Bluesky handle, their self-hosted PDS, or any compatible identity provider. No Auth0, no Firebase, no centralized user database. The content syncs to the user's own PDS using shared lexicons from Standard.site~\citep{standardsite2025}. 110 110 + 111 111 + We examine how this model applies to Aesthetic Computer---a creative computing platform with 600+ interactive pieces, multiplayer sessions, a KidLisp programming language, and a native bare-metal OS~\citep{scudder2026os}---and propose a phased migration that preserves backward compatibility while moving toward decentralized identity. 112 112 + 113 113 + % ============ 2. THE CURRENT AC IDENTITY ARCHITECTURE ============ 114 114 + 115 115 + \section{Current Architecture} 116 116 + \label{sec:current} 117 117 + 118 118 + \subsection{Auth0 as Identity Provider} 119 119 + 120 120 + Authentication flows through Auth0's SPA SDK. On page load, \texttt{boot.mjs} checks localStorage for cached Auth0 state. If a session exists (or an OAuth callback is detected), it initializes the Auth0 client with PKCE and refresh tokens, exchanges authorization codes for access tokens, and retrieves the user profile. The Auth0 \texttt{sub} field (e.g., \texttt{auth0|abc123} or \texttt{google-oauth2|xyz}) serves as the internal user identifier. 121 121 + 122 122 + \begin{lstlisting}[style=acjsstyle] 123 123 + // boot.mjs: current Auth0 flow 124 124 + const auth0 = await createAuth0Client({ 125 125 + domain: |\textcolor{jsstr}{"hi.aesthetic.computer"}|, 126 126 + clientId: |\textcolor{jsstr}{"LVdZaM..."}|, 127 127 + cacheLocation: |\textcolor{jsstr}{"localstorage"}|, 128 128 + useRefreshTokens: true, 129 129 + }); 130 130 + const user = await auth0.getUser(); 131 131 + // { sub, email, email_verified, ... } 132 132 + \end{lstlisting} 133 133 + 134 134 + \subsection{Handle System} 135 135 + 136 136 + Handles are stored in a MongoDB \texttt{@handles} collection, mapping Auth0 \texttt{sub} to a 1--16 character alphanumeric string (with \texttt{.} and \texttt{\_} allowed). Validation enforces no leading/trailing punctuation, case-insensitive uniqueness, and profanity filtering. Handles are the primary user-facing identity: URL-addressable (\texttt{@handle/piece-name}), visible in chat, and spoken aloud by AC Native OS. 137 137 + 138 138 + \subsection{ATProto Shadow Identity} 139 139 + 140 140 + On first email verification, an Auth0 webhook triggers \texttt{createAtprotoAccount()}, which: 141 141 + 142 142 + \begin{enumerate} 143 143 + \item Generates a 32-character password 144 144 + \item Creates an invite code on the PDS 145 145 + \item Creates an account at \texttt{handle.at.aesthetic.computer} 146 146 + \item Stores the DID, handle, and encrypted password in MongoDB (\texttt{users.atproto}) 147 147 + \end{enumerate} 148 148 + 149 149 + When a user changes their AC handle, \texttt{updateAtprotoHandle()} syncs the change to the PDS. Content (paintings, moods, KidLisp snippets, tapes, news) is mirrored to the PDS via six custom lexicons (\texttt{computer.aesthetic.*}). The ATProto identity is real and functional---but the user never authenticates through it. It is a shadow identity: present, synced, but not sovereign. 150 150 + 151 151 + \subsection{The Duplication Problem} 152 152 + 153 153 + This architecture means: 154 154 + 155 155 + \begin{itemize} 156 156 + \item Two credential stores (Auth0 + PDS) 157 157 + \item Two handle namespaces (AC handles + PDS handles) 158 158 + \item Two sync paths (handle changes propagate Auth0 $\to$ MongoDB $\to$ PDS) 159 159 + \item A paid dependency (Auth0 subscription) 160 160 + \item No interoperability (a Bluesky user cannot sign into AC with their existing identity) 161 161 + \end{itemize} 162 162 + 163 163 + The PDS already knows who each user is. It already stores their DID, their handle, their content. The Auth0 layer adds cost and complexity without adding capability that the PDS cannot provide. 164 164 + 165 165 + % ============ 3. THE AT PROTOCOL IDENTITY STACK ============ 166 166 + 167 167 + \section{The AT Protocol Identity Stack} 168 168 + \label{sec:atproto} 169 169 + 170 170 + Understanding the migration requires understanding the three layers of \atproto{} identity: DIDs, handles, and OAuth. 171 171 + 172 172 + \subsection{Decentralized Identifiers (DIDs)} 173 173 + 174 174 + A DID~\citep{w3cdid2022, atproto2024did} is a persistent, cryptographically verifiable identifier. The \atproto{} primarily uses \texttt{did:plc}, a method designed for strong consistency, high availability, and key rotation without losing identity. Each DID resolves to a document containing: 175 175 + 176 176 + \begin{itemize} 177 177 + \item A \textbf{signing key} (P-256 or K-256)~\citep{atproto2024crypto} for authenticating repository updates 178 178 + \item \textbf{Rotation keys} for account recovery 179 179 + \item A \textbf{PDS endpoint} URL 180 180 + \item The user's current \textbf{handle} 181 181 + \end{itemize} 182 182 + 183 183 + The DID is the stable identity. Handles change; keys rotate; PDS providers come and go. The DID persists. AC already mints DIDs for every user through its PDS. The infrastructure exists. 184 184 + 185 185 + \subsection{Handle Verification} 186 186 + 187 187 + An \atproto{} handle~\citep{atproto2024handle} is a domain name that bidirectionally resolves to a DID. Verification uses two methods: 188 188 + 189 189 + \textbf{DNS TXT}: Place a record at \texttt{\_atproto.example.com}: 190 190 + \begin{lstlisting} 191 191 + _atproto.example.com TXT "did=did:plc:abc..." 192 192 + \end{lstlisting} 193 193 + 194 194 + \textbf{HTTPS Well-Known}: Serve the DID at: 195 195 + \begin{lstlisting} 196 196 + GET /.well-known/atproto-did 197 197 + Response: did:plc:abc... 198 198 + \end{lstlisting} 199 199 + 200 200 + Both methods require the handle to resolve to the DID \emph{and} the DID document to claim the handle back. This bidirectional verification means: if you control the domain, you control the handle. No central authority assigns handles; DNS is the authority. 201 201 + 202 202 + For AC, this means \texttt{jeffrey.at.aesthetic.computer} is a real, verifiable ATProto handle because AC controls both the DNS and the PDS. But it also means a user who already owns \texttt{alice.bsky.social} or \texttt{alice.dev} has a cryptographically verified identity that AC can trust without a password. 203 203 + 204 204 + \subsection{ATProto OAuth} 205 205 + 206 206 + The \atproto{} OAuth specification~\citep{atproto2024oauth} extends OAuth 2.1 with three mandatory security mechanisms: 207 207 + 208 208 + \textbf{PKCE} (Proof Key for Code Exchange)~\citep{rfc7636pkce}: Prevents authorization code interception. The client generates a random verifier, sends its hash with the authorization request, and proves possession of the original verifier during token exchange. 209 209 + 210 210 + \textbf{PAR} (Pushed Authorization Requests)~\citep{rfc9126par}: The client submits authorization parameters via POST to the authorization server \emph{before} redirecting the user. This prevents parameter tampering in the redirect URL. 211 211 + 212 212 + \textbf{DPoP} (Demonstrating Proof of Possession)~\citep{rfc9449dpop}: Each request includes a signed JWT proving the client holds the private key associated with the token. Even if an access token leaks, it cannot be used by a different client. 213 213 + 214 214 + \subsubsection{Client Identification} 215 215 + 216 216 + Unlike traditional OAuth, \atproto{} does not require pre-registration with each authorization server. Instead, clients publish metadata at a public HTTPS URL: 217 217 + 218 218 + \begin{lstlisting}[style=acjsstyle] 219 219 + // aesthetic.computer/oauth/client-metadata.json 220 220 + { 221 221 + |\textcolor{jsstr}{"client\_id"}|: |\textcolor{jsstr}{"https://aesthetic.computer/..."}|, 222 222 + |\textcolor{jsstr}{"client\_name"}|: |\textcolor{jsstr}{"Aesthetic Computer"}|, 223 223 + |\textcolor{jsstr}{"redirect\_uris"}|: [|\textcolor{jsstr}{"https://..."}|], 224 224 + |\textcolor{jsstr}{"grant\_types"}|: [|\textcolor{jsstr}{"authorization\_code"}|], 225 225 + |\textcolor{jsstr}{"dpop\_bound\_access\_tokens"}|: true 226 226 + } 227 227 + \end{lstlisting} 228 228 + 229 229 + Any PDS can discover and verify the client by fetching this URL. No pre-shared secrets, no app store registration, no API key management. 230 230 + 231 231 + \subsubsection{The Flow} 232 232 + 233 233 + \begin{enumerate} 234 234 + \item User enters their handle (e.g., \texttt{alice.bsky.social}) 235 235 + \item Client resolves handle $\to$ DID $\to$ PDS endpoint $\to$ authorization server 236 236 + \item Client pushes authorization parameters via PAR 237 237 + \item User is redirected to their PDS's authorization UI 238 238 + \item User approves; PDS redirects back with authorization code 239 239 + \item Client exchanges code for DPoP-bound access token 240 240 + \item Client verifies the returned DID matches the expected identity 241 241 + \end{enumerate} 242 242 + 243 243 + The critical difference from Auth0: the user authenticates with \emph{their own server}. AC never sees a password. The PDS---whether Bluesky's, AC's own, or a self-hosted instance---is the identity authority. 244 244 + 245 245 + % ============ 4. HOW PCKT.BLOG DOES IT ============ 246 246 + 247 247 + \section{Case Study: pckt.blog} 248 248 + \label{sec:pckt} 249 249 + 250 250 + pckt.blog~\citep{pcktblog2025} is a blogging platform that authenticates exclusively through \atproto{} OAuth. Its implementation demonstrates the practical viability of ATProto-only authentication for a content platform. 251 251 + 252 252 + \subsection{Authentication} 253 253 + 254 254 + Users sign in by entering their ATProto handle. pckt.blog resolves the handle, discovers the authorization server, and initiates the OAuth flow. The user approves on their PDS (Bluesky, Blacksky, a self-hosted server). pckt.blog receives a DPoP-bound access token and the user's DID. No passwords are stored. No separate user database is maintained. 255 255 + 256 256 + \subsection{Data Sovereignty} 257 257 + 258 258 + Content syncs to the user's own PDS using Standard.site lexicons~\citep{standardsite2025}: 259 259 + 260 260 + \begin{itemize} 261 261 + \item \texttt{site.standard.publication} --- blog collections 262 262 + \item \texttt{site.standard.document} --- individual articles 263 263 + \item \texttt{site.standard.graph.subscription} --- follow relationships 264 264 + \end{itemize} 265 265 + 266 266 + If pckt.blog disappears, the user's content remains on their PDS, accessible to any compatible reader. This is the promise of ATProto: the platform is a view, not a silo. 267 267 + 268 268 + \subsection{Implications for AC} 269 269 + 270 270 + pckt.blog proves that a content-oriented platform can operate entirely on ATProto identity. The parallels to AC are direct: 271 271 + 272 272 + \begin{itemize} 273 273 + \item pckt.blog publishes articles; AC publishes pieces, paintings, and moods 274 274 + \item pckt.blog uses Standard.site lexicons; AC has six custom \texttt{computer.aesthetic.*} lexicons 275 275 + \item pckt.blog's users own their content on their PDS; AC already mirrors content to its PDS 276 276 + \item Both are Node.js/JavaScript applications 277 277 + \end{itemize} 278 278 + 279 279 + The gap: pckt.blog was built ATProto-native. AC has an existing Auth0 user base that must be migrated gracefully. 280 280 + 281 281 + % ============ 5. PROPOSED MIGRATION ============ 282 282 + 283 283 + \section{Proposed Migration} 284 284 + \label{sec:migration} 285 285 + 286 286 + \subsection{Phase 1: ATProto OAuth as Secondary Sign-In} 287 287 + 288 288 + Add ``Sign in with Bluesky'' alongside Auth0, without removing Auth0. 289 289 + 290 290 + \textbf{Infrastructure:} 291 291 + \begin{enumerate} 292 292 + \item Publish client metadata at \texttt{aesthetic.computer/oauth/client-metadata.json} 293 293 + \item Add \texttt{@atproto/oauth-client-node}~\citep{npmAtprotoOauth} to the backend 294 294 + \item Create two new Netlify functions: 295 295 + \begin{itemize} 296 296 + \item \texttt{POST /api/atproto-auth/start} --- resolve handle, PAR, redirect 297 297 + \item \texttt{GET /api/atproto-auth/callback} --- code exchange with DPoP 298 298 + \end{itemize} 299 299 + \item Store sessions in Redis (DID, handle, DPoP key pair, tokens) 300 300 + \end{enumerate} 301 301 + 302 302 + \textbf{Client flow:} A new ``Sign in with Bluesky'' button in \texttt{boot.mjs} triggers the ATProto OAuth flow. On success, \texttt{window.acUSER} is populated from the ATProto session (DID as \texttt{sub}, handle, no email unless the user provides one). The piece API surface is identical---pieces see a user with a handle, regardless of which auth path created the session. 303 303 + 304 304 + \subsection{Phase 2: Handle Bridging} 305 305 + 306 306 + When a user signs in via ATProto, bridge their handle to AC: 307 307 + 308 308 + \begin{enumerate} 309 309 + \item Extract the username from the ATProto handle (e.g., \texttt{alice} from \texttt{alice.bsky.social}) 310 310 + \item Check availability against the AC \texttt{@handles} collection 311 311 + \item If available and valid (1--16 chars, alphanumeric), offer one-click claim 312 312 + \item If taken, check if the existing owner's email matches---offer account linking 313 313 + \item If taken by someone else, prompt for an alternative 314 314 + \item Store a DID $\leftrightarrow$ AC sub mapping in MongoDB for future sign-ins 315 315 + \end{enumerate} 316 316 + 317 317 + Custom domain handles (e.g., \texttt{alice.dev}) require the user to choose an AC handle manually, since the domain itself may not map to a valid handle string. 318 318 + 319 319 + \subsection{Phase 3: Identity Linking} 320 320 + 321 321 + Existing Auth0 users can link their ATProto identity: 322 322 + 323 323 + \begin{enumerate} 324 324 + \item From account settings, initiate ATProto OAuth 325 325 + \item On success, store the external DID alongside the Auth0 sub 326 326 + \item Future sign-ins accept either auth path 327 327 + \item Content can optionally sync to the user's external PDS (not just AC's PDS) 328 328 + \end{enumerate} 329 329 + 330 330 + This phase turns the existing \texttt{users.atproto} field from a shadow identity into a first-class identity link. 331 331 + 332 332 + \subsection{Phase 4: ATProto-Primary} 333 333 + 334 334 + Once the migration is validated: 335 335 + 336 336 + \begin{enumerate} 337 337 + \item New signups default to ATProto OAuth (creating accounts on AC's PDS) 338 338 + \item Auth0 remains as a legacy path for existing users 339 339 + \item Gradually sunset Auth0 as users link their ATProto identities 340 340 + \item Remove Auth0 dependency, eliminate subscription cost 341 341 + \end{enumerate} 342 342 + 343 343 + \subsection{PDS Routing} 344 344 + 345 345 + A key architectural decision: where does content go? 346 346 + 347 347 + \begin{itemize} 348 348 + \item \textbf{Auth0-only users}: content syncs to AC's PDS (current behavior) 349 349 + \item \textbf{ATProto users with external PDS}: content syncs to \emph{their} PDS 350 350 + \item \textbf{ATProto users on AC's PDS}: content stays on AC's PDS 351 351 + \end{itemize} 352 352 + 353 353 + This means the backend sync functions (\texttt{media-atproto.mjs}, \texttt{painting-atproto.mjs}, etc.) need a conditional path: resolve the user's PDS endpoint from their DID document, and write to that endpoint rather than assuming AC's PDS. 354 354 + 355 355 + % ============ 6. HANDLE SEMANTICS ============ 356 356 + 357 357 + \section{Handle Semantics} 358 358 + \label{sec:handles} 359 359 + 360 360 + The handle is the most human-visible piece of the identity stack, and the migration raises questions about what a handle \emph{means}. 361 361 + 362 362 + \subsection{Current Handle Model} 363 363 + 364 364 + Today, an AC handle is: 365 365 + \begin{itemize} 366 366 + \item A 1--16 character string, first-come-first-served 367 367 + \item Unique within the AC namespace 368 368 + \item Used for URLs (\texttt{@alice/painting}), chat, and OS personalization 369 369 + \item Stored in MongoDB, cached in Redis 370 370 + \item Mirrored to the PDS as \texttt{alice.at.aesthetic.computer} 371 371 + \end{itemize} 372 372 + 373 373 + \subsection{ATProto Handle Model} 374 374 + 375 375 + An ATProto handle is: 376 376 + \begin{itemize} 377 377 + \item A domain name (any valid DNS name) 378 378 + \item Verified bidirectionally against a DID 379 379 + \item Globally unique by DNS authority 380 380 + \item Portable across services 381 381 + \end{itemize} 382 382 + 383 383 + \subsection{Bridging the Models} 384 384 + 385 385 + The proposal: an AC handle is an \emph{alias} that maps to a DID. The source of truth shifts from MongoDB to the DID layer. Multiple sign-in methods (Auth0, ATProto OAuth) resolve to the same DID, which resolves to the same AC handle. 386 386 + 387 387 + For AC Native OS~\citep{scudder2026os}, where the handle is inscribed in \texttt{config.json} on the boot partition, this means the device identity is backed by a cryptographic identity. ``Hi @alice'' on the boot screen means Alice's DID, Alice's signing key, Alice's portable identity---not just a string in a config file. 388 388 + 389 389 + % ============ 7. OPEN QUESTIONS ============ 390 390 + 391 391 + \section{Open Questions} 392 392 + \label{sec:questions} 393 393 + 394 394 + \textbf{Handle priority.} If \texttt{alice} is unclaimed on AC but \texttt{alice.bsky.social} signs in, should she get it automatically? First-come-first-served is simple but allows squatting. ATProto-verified priority is fairer but adds complexity. 395 395 + 396 396 + \textbf{Email requirement.} Auth0 provides verified email for account recovery. ATProto OAuth does not guarantee email. Should AC require an email for full account features (purchasing, notifications)? 397 397 + 398 398 + \textbf{Multi-tenant.} AC operates a second tenant (\texttt{sotce}) with separate Auth0. How do ATProto identities map across tenants? The DID is tenant-agnostic, which may simplify cross-tenant identity. 399 399 + 400 400 + \textbf{Session server.} Real-time features (chat, multiplayer) authenticate via Auth0 tokens forwarded through WebSocket. The session server must accept ATProto-issued tokens or a unified session token. 401 401 + 402 402 + \textbf{Device pairing.} AC Native OS pairs via a 6-character code exchanged through Auth0. The ATProto equivalent: scan a QR code that initiates an OAuth flow on the phone, delivering tokens to the device. 403 403 + 404 404 + \textbf{Admin identity.} Admin is currently \texttt{handle === "jeffrey" \&\& sub === ADMIN\_SUB}. Under ATProto-first auth, admin is \texttt{did === admin\_did}---cleaner, cryptographically grounded. 405 405 + 406 406 + % ============ 8. RELATED WORK ============ 407 407 + 408 408 + \section{Related Work} 409 409 + \label{sec:related} 410 410 + 411 411 + \textbf{Decentralized identity.} The W3C DID specification~\citep{w3cdid2022} provides the formal framework for decentralized identifiers. The AT Protocol's \texttt{did:plc} method~\citep{atproto2024did} extends this with strong consistency guarantees and a centralized-but-auditable directory at \texttt{plc.directory}. This is a pragmatic compromise: full decentralization of identity resolution remains an open problem, and \texttt{did:plc} trades some decentralization for operational reliability. 412 412 + 413 413 + \textbf{ATProto-native applications.} pckt.blog~\citep{pcktblog2025} demonstrates blogging; Leaflet.pub and Offprint.app collaborate on shared lexicons via Standard.site~\citep{standardsite2025}. These applications prove the viability of ATProto-only auth for content platforms. 414 414 + 415 415 + \textbf{OAuth security.} DPoP~\citep{rfc9449dpop} prevents token theft; PAR~\citep{rfc9126par} prevents parameter tampering; PKCE~\citep{rfc7636pkce} prevents code interception. Together they represent the state of the art in browser-based OAuth security---significantly stronger than the Auth0 SPA flow AC currently uses. 416 416 + 417 417 + \textbf{Convivial identity.} Illich's tools for conviviality~\citep{illich1973tools} frame the question: does the identity system expand personal autonomy, or does it require dependence on a provider? Auth0 is a managed service---convenient but dependent. ATProto identity is portable, self-verifiable, and provider-independent. Nelson's vision of personal computing~\citep{nelson1974computerlib} extends naturally to personal identity: you should own your name on the network. 418 418 + 419 419 + % ============ 9. CONCLUSION ============ 420 420 + 421 421 + \section{Conclusion} 422 422 + 423 423 + Aesthetic Computer already runs a PDS, mints DIDs, syncs content to ATProto records, and publishes custom lexicons. The only piece missing is letting users authenticate through that infrastructure instead of routing through Auth0. The migration is not a rewrite---it is the removal of a workaround. 424 424 + 425 425 + The phased approach (ATProto as secondary sign-in $\to$ handle bridging $\to$ identity linking $\to$ ATProto-primary) ensures no existing user is disrupted. The end state: a creative computing platform where your handle is a cryptographic identity, your content lives on a server you control, and signing in means proving you own your keys---not trusting a third party to vouch for you. 426 426 + 427 427 + The PDS is already running. The DIDs are already minted. The lexicons are already published. It is time to let users sign in through the front door. 428 428 + 429 429 + % ============ REFERENCES ============ 430 430 + 431 431 + \vspace{0.5em} 432 432 + \noindent\rule{\columnwidth}{0.5pt} 433 433 + 434 434 + \subsection*{Reference Links} 435 435 + 436 436 + \noindent\small 437 437 + 438 438 + \textbf{AT Protocol Specifications:} 439 439 + \begin{itemize} 440 440 + \item \url{https://atproto.com/specs} --- Full protocol specification 441 441 + \item \url{https://atproto.com/specs/oauth} --- OAuth specification 442 442 + \item \url{https://atproto.com/specs/handle} --- Handle resolution 443 443 + \item \url{https://atproto.com/specs/cryptography} --- Cryptographic methods 444 444 + \item \url{https://web.plc.directory/spec/v0.1/did-plc} --- DID PLC specification 445 445 + \item \url{https://atproto.com/guides/lexicon} --- Lexicon schema system 446 446 + \item \url{https://atproto.com/guides/oauth-patterns} --- OAuth implementation patterns 447 447 + \end{itemize} 448 448 + 449 449 + \textbf{Implementation Guides:} 450 450 + \begin{itemize} 451 451 + \item \url{https://docs.bsky.app/blog/oauth-atproto} --- Building ATProto OAuth apps 452 452 + \item \url{https://docs.bsky.app/docs/advanced-guides/resolving-identities} --- Identity resolution 453 453 + \item \url{https://docs.bsky.app/docs/advanced-guides/oauth-client} --- OAuth client guide 454 454 + \end{itemize} 455 455 + 456 456 + \textbf{NPM Packages:} 457 457 + \begin{itemize} 458 458 + \item \texttt{@atproto/oauth-client-node} --- Node.js OAuth client 459 459 + \item \texttt{@atproto/oauth-client-browser} --- Browser OAuth client 460 460 + \item \texttt{@atproto/api} --- TypeScript XRPC client 461 461 + \item \texttt{@atproto/identity} --- DID/handle resolution 462 462 + \item \texttt{@atcute/oauth-browser-client} --- Lightweight alternative 463 463 + \end{itemize} 464 464 + 465 465 + \textbf{Reference Implementations:} 466 466 + \begin{itemize} 467 467 + \item \url{https://github.com/pilcrowonpaper/atproto-oauth-example} --- Astro OAuth example 468 468 + \item \url{https://github.com/bluesky-social/atproto} --- Official ATProto monorepo 469 469 + \item \url{https://standard.site/docs/introduction/} --- Standard.site shared lexicons 470 470 + \end{itemize} 471 471 + 472 472 + \textbf{Applications Using ATProto Auth:} 473 473 + \begin{itemize} 474 474 + \item pckt.blog --- Blogging on the open social web 475 475 + \item Leaflet.pub --- Long-form publishing 476 476 + \item Offprint.app --- Collaborative writing 477 477 + \end{itemize} 478 478 + 479 479 + \textbf{IETF Standards:} 480 480 + \begin{itemize} 481 481 + \item RFC 9449 --- DPoP (Demonstrating Proof of Possession) 482 482 + \item RFC 7636 --- PKCE (Proof Key for Code Exchange) 483 483 + \item RFC 9126 --- PAR (Pushed Authorization Requests) 484 484 + \end{itemize} 485 485 + 486 486 + \vspace{0.5em} 487 487 + 488 488 + \bibliographystyle{plainnat} 489 489 + \bibliography{references} 490 490 + 491 491 + \end{document}

+439

papers/arxiv-open-schools/open-schools-cards.tex

reviewed

··· 1 1 + % !TEX program = xelatex 2 2 + % Cards format — auto-generated from open-schools.tex by cards-convert.mjs 3 3 + \documentclass[11pt]{article} 4 4 + 5 5 + \usepackage{fontspec} 6 6 + \usepackage{unicode-math} 7 7 + \setmainfont{Latin Modern Roman} 8 8 + \setsansfont{Latin Modern Sans} 9 9 + \setmonofont{Latin Modern Mono}[Scale=0.88] 10 10 + 11 11 + 12 12 + \usepackage{graphicx} 13 13 + \graphicspath{{figures/}{../arxiv-ac/figures/}} 14 14 + \usepackage{booktabs} 15 15 + \usepackage{tabularx} 16 16 + \usepackage{ragged2e} 17 17 + \usepackage{microtype} 18 18 + \usepackage{natbib} 19 19 + 20 20 + 21 21 + 22 22 + \makeatletter 23 23 + \def\input@path{{../}} 24 24 + \makeatother 25 25 + \usepackage{ac-paper-cards} 26 26 + 27 27 + % Extra commands from base paper 28 28 + \newcommand{\acos}{\textsc{AC Native OS}} 29 29 + 30 30 + \hypersetup{ 31 31 + pdftitle={Get Closed Source Out of Schools: Every Chromebook Is a Gateway Denied}, 32 32 + } 33 33 + 34 34 + \renewcommand{\acpdfbase}{open-schools-26-arxiv} 35 35 + \begin{document} 36 36 + 37 37 + % ============================================================ 38 38 + % TITLE CARD 39 39 + % ============================================================ 40 40 + \thispagestyle{empty} 41 41 + \vspace*{\fill} 42 42 + \begin{center} 43 43 + \includegraphics[height=9em]{pals}\par\vspace{0.1em} 44 44 + {\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Get Closed Source Out of Schools}\par 45 45 + \vspace{0.1em} 46 46 + \vspace{0.3em} 47 47 + {\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par 48 48 + {\small\color{acgray} Aesthetic.Computer}\par 49 49 + {\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par 50 50 + \vspace{0.4em} 51 51 + \rule{0.5\textwidth}{0.5pt}\par 52 52 + \vspace{0.15em} 53 53 + \colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par 54 54 + \vspace{0.1em} 55 55 + {\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/894fbcb44}{894fbcb44}}\par 56 56 + \end{center} 57 57 + \vspace*{\fill} 58 58 + 59 59 + % ============================================================ 60 60 + % INDEX CARD 61 61 + % ============================================================ 62 62 + \cardindex 63 63 + 64 64 + % ============================================================ 65 65 + % ABSTRACT CARD 66 66 + % ============================================================ 67 67 + \clearpage 68 68 + \begin{accentcard} 69 69 + \cardtitle{Abstract} 70 70 + 71 71 + \noindent 72 72 + There are over 50 million Chromebooks in American schools. Each one is a capable computer running a locked-down, closed-source operating system that funnels every student interaction through Google's surveillance infrastructure. The student cannot see how the machine works. The student cannot modify the machine. The student cannot own the machine in any meaningful sense. In the age of large language models---when ``everyone is a programmer'' is no longer a slogan but a material reality---this is an act of educational malpractice. This paper argues that every student deserves a free and open operating system stack: one where the Chromebook becomes a gateway to the student's own path through logic, creativity, the internet, community, and the computational landscape as a whole. We present the technical, pedagogical, economic, and political case for replacing closed-source school computing infrastructure with open alternatives, drawing on international precedents from Kerala, Schleswig-Holstein, and France, environmental data on planned obsolescence, federal and state legal actions against student surveillance, and emerging research on AI-assisted programming education. We present \acos{}~\citep{scudder2026acos} as one concrete implementation of this vision. 73 73 + \end{accentcard} 74 74 + 75 75 + % ============================================================ 76 76 + % BODY 77 77 + % ============================================================ 78 78 + \section{The Chromebook Problem} 79 79 + 80 80 + In 2012, Google began aggressively marketing Chromebooks to American school districts. The pitch was simple: cheap hardware, zero IT overhead, everything in the cloud. By 2026, Chromebooks account for roughly 60\% of devices shipped to U.S. K--12 schools, with an installed base exceeding 50 million units~\citep{google2024chromeos}. An entire generation of American students is being educated on machines they cannot understand, cannot modify, and do not own---even when the school paid for them. 81 81 + 82 82 + ChromeOS is proprietary software. Its source is not available for inspection. The browser is the entire interface. Every document lives in Google Drive. Every search goes through Google. Every interaction is logged, analyzed, and used to build behavioral profiles that follow the student into adulthood~\citep{zuboff2019surveillance}. 83 83 + 84 84 + This is not a privacy concern at the margins. This is the \emph{architecture} of how American children learn to use computers. The medium is the message~\citep{mcluhan1964understanding}: the Chromebook teaches that a computer is a device for consuming cloud services owned by a corporation. It teaches that your work lives on someone else's server. It teaches that the machine is not yours to understand. 85 85 + 86 86 + \subsection{What the Student Cannot Do} 87 87 + 88 88 + On a school Chromebook, a student cannot: 89 89 + 90 90 + \begin{itemize} 91 91 + \item Install a programming language runtime (Python, Node.js, GCC) 92 92 + \item Run a local web server or compile code 93 93 + \item Inspect the operating system source 94 94 + \item Modify the boot sequence 95 95 + \item Connect to hardware peripherals for physical computing 96 96 + \item Use the machine offline for serious work 97 97 + \item Keep their data on the device without cloud sync 98 98 + \item Choose their own software 99 99 + \item Understand what the machine is doing with their attention 100 100 + \end{itemize} 101 101 + 102 102 + ChromeOS includes a Linux container (Crostini) that could theoretically provide these capabilities, but school IT administrators almost universally disable it. The machine ships with a terminal and then locks it shut. Every one of these restrictions is a door closed. Every closed door is a path the student will never discover. The Chromebook is not a gateway---it is a \emph{gate}. 103 103 + 104 104 + \subsection{The Cloud as Landlord} 105 105 + 106 106 + When a student's work lives in Google Drive, they are tenants, not owners. Google can change the terms of service. Google can discontinue products. Google can revoke access. The student graduates and loses their school Google account---and with it, every document, every project, every creative artifact they produced during their education. 107 107 + 108 108 + This is not hypothetical. It happens every year, in every school district. Students lose access to years of work because the institution that purchased their cloud account decommissions it. The architecture \emph{guarantees} this outcome: the student never had their files. They had permission to access files on Google's servers, and that permission was revoked. 109 109 + 110 110 + Freire called this the ``banking model'' of education~\citep{freire1970pedagogy}: knowledge deposited into students by authorities. The Chromebook literalizes the metaphor. The student's work is deposited into a bank they do not control, cannot audit, and will eventually be locked out of. 111 111 + 112 112 + \subsection{Planned Obsolescence: The AUE Problem} 113 113 + 114 114 + Every Chromebook ships with an Auto Update Expiration (AUE) date, after which Google provides no security patches, no feature updates, and no browser updates. Historically set at 6.5 years from the \emph{platform's} first release---not the purchase date---a school buying a Chromebook late in a platform cycle might receive only 3--4 years of updates. Google extended this to 10 years for devices launched in 2024, but the installed base of shorter-lived machines remains enormous. 115 115 + 116 116 + The U.S. PIRG Education Fund estimated that AUE policies would force the premature disposal of 21.5 million functionally working Chromebooks by 2024, costing schools approximately \$1.8 billion in unnecessary replacements~\citep{pirg2023chromebook}. These are machines with working processors, working screens, working keyboards---rendered obsolete by a software policy, not by hardware failure. 117 117 + 118 118 + The contrast with Linux is absolute. A 2015 ThinkPad running Ubuntu LTS continues to receive security updates indefinitely. There is no artificial expiration date tied to the hardware model. The machine remains useful as long as the hardware functions. 119 119 + 120 120 + % ============================================================ 121 121 + % 2. THE SURVEILLANCE MACHINE 122 122 + % ============================================================ 123 123 + 124 124 + \section{The Surveillance Machine} 125 125 + \label{sec:surveillance} 126 126 + 127 127 + Google provides Chromebooks to schools below cost because students are a captive market for behavioral data~\citep{zuboff2019surveillance, doctorow2020attack}. A student who grows up in the Google ecosystem---Gmail, Google Docs, Google Drive, Google Classroom, YouTube---is a customer for life. The Chromebook is not a charitable donation. It is a customer acquisition strategy deployed against children. 128 128 + 129 129 + \subsection{What Google Collects} 130 130 + 131 131 + The data collected from student Chromebooks includes: 132 132 + 133 133 + \begin{itemize} 134 134 + \item Every search query and every website visited 135 135 + \item Every document opened, edited, and shared 136 136 + \item Every YouTube video watched and for how long 137 137 + \item Keystroke timing patterns and login frequency 138 138 + \item Location data (on cellular models) 139 139 + \item Social graphs (who collaborates with whom in Google Docs) 140 140 + \item Device diagnostics and app usage telemetry 141 141 + \end{itemize} 142 142 + 143 143 + Google claims that data collected under Workspace for Education ``core services'' is not used for advertising. But ``additional services''---YouTube, Google Search, Google Maps when signed in---operate under different terms. Students on school Chromebooks use these additional services constantly, and the data flows to Google's advertising infrastructure. 144 144 + 145 145 + \subsection{Legal Actions} 146 146 + 147 147 + The legal record is damning. In 2019, Google paid \$170 million to the FTC and New York Attorney General for YouTube's COPPA violations---collecting data from children without parental consent~\citep{google2019coppa}. In 2020, New Mexico Attorney General Hector Balderas sued Google directly for collecting personal data from children using Chromebooks in schools~\citep{newmexico2020google}. The EFF filed an FTC complaint in 2015 documenting that Google was data-mining student browsing activity through Chromebooks~\citep{eff2015chromebook}. In 2024, a coalition of digital rights organizations filed additional FTC complaints regarding ongoing student surveillance~\citep{eff2024monitoring}. Class actions alleging biometric data collection from students under Illinois' BIPA statute are ongoing. 148 148 + 149 149 + This data is collected from minors, in an institutional setting where participation is mandatory, on machines the student did not choose and cannot configure. The student cannot opt out. The parent often cannot opt out. The school district signed a contract, and the children are bound by it. 150 150 + 151 151 + \subsection{Monitoring Software} 152 152 + 153 153 + Beyond Google's own data collection, school districts layer additional surveillance software---Gaggle, GoGuardian, Securly---onto Chromebooks. The EFF documented that these tools surveil private communications and disproportionately target disadvantaged, minority, and LGBTQ youth~\citep{eff2024monitoring}. Of 152 ed-tech services surveyed by the EFF, only 118 had published privacy policies; far fewer addressed data retention, encryption, or de-identification. 154 154 + 155 155 + Winner argued that artifacts have politics~\citep{winner1980artifacts}. The Chromebook's politics are clear: it is an instrument of surveillance deployed in a context where the surveilled have no choice, no recourse, and no understanding of what is being taken from them. 156 156 + 157 157 + A free and open operating system collects no telemetry. It phones home to no corporation. It builds no behavioral profile. The student's attention, their curiosity, their mistakes, their explorations---all of these remain private, because the machine has no economic incentive to observe them. 158 158 + 159 159 + % ============================================================ 160 160 + % 3. THE LLM INFLECTION 161 161 + % ============================================================ 162 162 + 163 163 + \section{Everyone Is a Programmer Now} 164 164 + 165 165 + Large language models have changed the economics of programming. A student who can describe what they want in natural language can produce working code. The barrier to computational creation has collapsed from ``years of technical training'' to ``the ability to articulate an idea.'' Karpathy's observation that ``the hottest new programming language is English'' is no longer hyperbole---it is a description of material reality. 166 166 + 167 167 + This is the most important shift in computing since the personal computer. And it makes the Chromebook problem \emph{catastrophically worse}. 168 168 + 169 169 + \subsection{The New Literacy} 170 170 + 171 171 + If everyone can program, then programming is literacy. And literacy requires tools the literate person can own. You do not teach a child to read by giving them a locked book that can only be opened in a specific building with a specific corporate account. You give them the book. They take it home. They read it in bed. They write in the margins. They lend it to a friend. 172 172 + 173 173 + A student with an LLM and an open operating system can: 174 174 + 175 175 + \begin{itemize} 176 176 + \item Build a tool to organize their homework 177 177 + \item Write a game and share it with classmates 178 178 + \item Automate a repetitive task their teacher assigns 179 179 + \item Create a small business selling software to their community 180 180 + \item Contribute to open-source projects that serve humanity 181 181 + \item Understand and modify the systems that govern their digital life 182 182 + \item Explore logic, mathematics, and language through direct manipulation 183 183 + \item Build instruments for artistic expression 184 184 + \end{itemize} 185 185 + 186 186 + A student with an LLM and a Chromebook can use Google Docs faster. 187 187 + 188 188 + Ko (University of Washington) has argued that if AI can write code, CS education must shift toward systems thinking, debugging, and evaluation---all of which require access to real development environments, not sandboxed browsers~\citep{denny2024computing}. Krishnamurthi (Brown University) has been critical of approaches that reduce programming to prompting. The emerging consensus in CS education research is that LLMs make full-stack access \emph{more} important, not less~\citep{prather2024robots}: students need to run, debug, modify, and understand generated code. Chromebooks make all four harder. 189 189 + 190 190 + \subsection{The Chromebook Cannot Execute} 191 191 + 192 192 + Here is the concrete failure: the LLM produces a Python script, and the Chromebook cannot run it. The LLM generates a web server, and the Chromebook cannot host it. The LLM writes C code, and the Chromebook has no compiler. The LLM teaches the student how an operating system works, and the Chromebook will not let them inspect one. 193 193 + 194 194 + On a typical school Chromebook (MediaTek or Celeron processor, 4\,GB RAM), even the Linux container---when enabled---struggles to run basic development toolchains. Running a local LLM is physically impossible: even a quantized 1B parameter model requires more memory than most school Chromebooks possess. 195 195 + 196 196 + The alternative is trivial. A surplus ThinkPad with 8\,GB RAM running Linux can execute any LLM-generated code, run a local 3B parameter model via Ollama at interactive speeds, host a web server, compile programs, and give the student root access to the entire system. The hardware exists. The software is free. The Chromebook is the bottleneck. 197 197 + 198 198 + \subsection{The Spiritual Dimension} 199 199 + 200 200 + This is not only about economics or career preparation. There is a spiritual dimension to computing that the Chromebook architecture annihilates. 201 201 + 202 202 + When a student writes a program that does something they did not expect---when the machine surprises them with emergent behavior from rules they defined---they experience something profound. They encounter the boundary between intention and consequence. They learn that systems have their own logic. They develop a relationship with abstraction itself. 203 203 + 204 204 + Papert understood this~\citep{papert1980mindstorms}: Logo was not about teaching programming. It was about giving children a medium for thinking about thinking. The turtle was a vehicle for epistemology. 205 205 + 206 206 + LLMs amplify this a thousandfold. A student can now have a \emph{conversation} with the computational medium. They can ask ``what if?'' and get an answer in seconds. They can iterate on ideas at the speed of thought. They can explore paths that no curriculum anticipated. 207 207 + 208 208 + But only if the machine lets them. A Chromebook does not let them. A Chromebook says: you may consume services. You may not create infrastructure. You may not run your own code in your own way on your own machine. 209 209 + 210 210 + % ============================================================ 211 211 + % 4. WHAT STUDENTS DESERVE 212 212 + % ============================================================ 213 213 + 214 214 + \section{What Every Student Deserves} 215 215 + 216 216 + Every student deserves a computer that: 217 217 + 218 218 + \begin{enumerate} 219 219 + \item \textbf{They can understand.} The source code of the operating system should be available for inspection. Not as an abstract principle, but as a practical reality: the student should be able to read the code that runs when they press a key. 220 220 + 221 221 + \item \textbf{They can modify.} If the student wants to change how the machine behaves, they should be able to. Not through an app store, not through a settings panel, but by changing the code. 222 222 + 223 223 + \item \textbf{They can own.} The student's work should live on the student's machine. Not on a corporate server, not in a cloud account that will be decommissioned when they graduate. 224 224 + 225 225 + \item \textbf{They can share.} The student should be able to give their software to a friend. Not through a platform, not through a marketplace, but by copying a file. 226 226 + 227 227 + \item \textbf{They can break.} The student should be able to break the machine and fix it. This is how you learn. A system that cannot be broken cannot be understood. 228 228 + 229 229 + \item \textbf{They can take with them.} When the student leaves the school, the computer---and everything on it---goes with them. Their computational life is not leased. It is theirs. 230 230 + 231 231 + \item \textbf{Respects their attention.} The operating system should not contain advertising, behavioral tracking, or engagement optimization. The student's attention belongs to the student. 232 232 + 233 233 + \item \textbf{Connects them to community.} The student should be able to contribute to the computational landscape---to write code that others use, to participate in open-source projects, to build tools that serve their community and maintain their lifestyle and wellbeing. 234 234 + \end{enumerate} 235 235 + 236 236 + Every one of these requirements is violated by ChromeOS. Every one of them is satisfied by a free and open operating system. 237 237 + 238 238 + % ============================================================ 239 239 + % 5. IT ALREADY WORKS 240 240 + % ============================================================ 241 241 + 242 242 + \section{It Already Works: International Precedents} 243 243 + 244 244 + The objection that open-source school computing is untested is false. It has been tested, at scale, on three continents. 245 245 + 246 246 + \subsection{Kerala, India: 16,000 Schools} 247 247 + 248 248 + Kerala's KITE (Kerala Infrastructure and Technology for Education) program moved entirely to free software in 2007 across 16,000+ public schools. KITE GNU/Linux 22.04, released in August 2024, runs on over 300,000 school computers~\citep{kite2024gnulinux}. The distribution includes educational software (Krita, GCompris, PictoBlox), basic AI/ML teaching tools, and a Wayland display server. The estimated savings: 30 billion INR (approximately \$400 million). Over 150,000 primary teachers have been trained. India's National Law School hailed KITE as the national benchmark for open-source transformation in education. 249 249 + 250 250 + This is not a pilot program. It is a state-wide deployment serving millions of students, running continuously for nearly two decades. 251 251 + 252 252 + \subsection{Schleswig-Holstein, Germany: 30,000 PCs} 253 253 + 254 254 + By end of summer 2025, the German state of Schleswig-Holstein completed migration of nearly 30,000 government PCs from Microsoft to Linux, with an additional 30,000 public school teachers expected to follow~\citep{schleswig2025linux}. Replacements include LibreOffice, Nextcloud, Open-Xchange, and Mozilla Thunderbird. Estimated savings: 15 million EUR in 2026 alone. Denmark announced a similar transition between June and November 2025. 255 255 + 256 256 + \subsection{France: National Open-Source Strategy} 257 257 + 258 258 + France's Digital Education Strategy 2023--2027, led by Alexis Kauffmann at the Ministry of Education, explicitly targets digital sovereignty and reduced dependence on Microsoft and Google~\citep{france2023digital}. The national platform \texttt{apps.education.fr} provides open-source tools to all French teachers. In 2025, France enacted an interoperability decree requiring schools to use digital tools complying with open standards---creating a structural advantage for open-source solutions. 259 259 + 260 260 + \subsection{Penn Manor, Pennsylvania: 1,725 Linux Laptops} 261 261 + 262 262 + In the United States, Penn Manor School District in Lancaster, PA deployed 1,725 Ubuntu laptops to students in grades 9--12~\citep{pennmanor2024linux}. The program includes a student-run repair initiative where students learn to fix their own machines. This is not a special district with special funding. It is a public school district that made a different choice. 263 263 + 264 264 + \subsection{The ``Public Money, Public Code'' Movement} 265 265 + 266 266 + The Free Software Foundation Europe's ``Public Money? Public Code!'' campaign---arguing that software developed with public funds should be released under free licenses---has gathered over 200 civil society organizations and 31,000 individual signatories~\citep{fsfe2024publiccode}. UNESCO's 2024 Dubai Declaration on Open Educational Resources formally commits signatories to advancing open resources through AI and emerging technologies~\citep{unesco2024oer}. The Global Digital Compact commits to ``developing, disseminating, and maintaining open-source software, open data, open AI models, and open standards that benefit society.'' 267 267 + 268 268 + These are not fringe movements. They are the direction of international policy. 269 269 + 270 270 + % ============================================================ 271 271 + % 6. THE ECONOMICS 272 272 + % ============================================================ 273 273 + 274 274 + \section{The Economics} 275 275 + 276 276 + \subsection{The Cost Excuse} 277 277 + 278 278 + Chromebooks are cheap. But so are surplus laptops running Linux. A retired ThinkPad T480 or Dell Latitude 5400 costs \$100--180 in bulk and is a superior machine in every dimension except ``managed by Google.'' The cost argument for Chromebooks is an argument for Google's ecosystem, not for the hardware. 279 279 + 280 280 + \begin{table}[H] 281 281 + \small 282 282 + \centering 283 283 + \begin{tabular}{lrr} 284 284 + \toprule 285 285 + \textbf{Approach} & \textbf{Cost} & \textbf{Student Owns It} \\ 286 286 + \midrule 287 287 + Chromebook (new) & \$250--350 & No \\ 288 288 + Chrome Edu Upgrade & +\$38/device & No \\ 289 289 + Google Workspace Plus & +\$5/student/yr & No \\ 290 290 + iPad (edu) & \$299+ & No \\ 291 291 + \midrule 292 292 + Surplus laptop + Linux & \$100--180 & \textbf{Yes} \\ 293 293 + Surplus laptop + AC OS & \$100--180 & \textbf{Yes} \\ 294 294 + \bottomrule 295 295 + \end{tabular} 296 296 + \caption{Cost and ownership comparison. Chromebook costs exclude monitoring software (GoGuardian: \$5--10/device/year) and forced AUE replacements.} 297 297 + \label{tab:cost} 298 298 + \end{table} 299 299 + 300 300 + When factoring in Google's Chrome Education Upgrade (\$38/device), Workspace for Education Plus (\$5/student/year), monitoring software, and the forced replacement cycle from AUE, the total cost of ownership for a Chromebook over 5 years can reach \$450--550/device. A surplus ThinkPad running Linux: \$100--180, with zero ongoing licensing costs, no artificial expiration, and the student keeps it. 301 301 + 302 302 + \subsection{The Supply} 303 303 + 304 304 + The machines exist. An estimated 50--60 million business PCs are retired annually in the United States. Corporate lease cycles retire millions of functional laptops every 3--5 years---machines with modern processors, 8--16\,GB RAM, WiFi, and 6--10 hour batteries. Organizations like PCs for People (100,000+ devices/year), Human-I-T (50,000+/year), Kramden Institute, Free Geek, and the federal Computers for Learning program already refurbish and distribute these machines. 305 305 + 306 306 + A classroom of 30 creative computing instruments can be provisioned for \$3,000--5,400 in hardware. No ongoing subscription. No IT support contract. No managed accounts. 307 307 + 308 308 + \subsection{The Environmental Case} 309 309 + 310 310 + A typical laptop produces 300--400 kg CO$_2$e in manufacturing---70--80\% of its total lifetime carbon footprint. Refurbishment adds approximately 5--15 kg CO$_2$e. Circular Computing's independently audited analysis found 316 kg CO$_2$e saved per remanufactured laptop~\citep{circularcomputing2023carbon}. The UN Global E-waste Monitor 2024 reports that the US generates approximately 7.2 Mt of e-waste annually, with only 25\% properly recycled~\citep{un2024ewaste}. 311 311 + 312 312 + Google's AUE policy forces schools to discard millions of working Chromebooks. Right-to-repair legislation is beginning to address this: Oregon's act (effective January 2025) requires manufacturers to provide parts and repair information~\citep{oregon2024repair}; New Hampshire's HB1701 explicitly covers school-provided laptops~\citep{newhampshire2024repair}. But legislation cannot fix a software policy that declares functional hardware obsolete. 313 313 + 314 314 + Linux has no AUE. A laptop running a free operating system remains useful as long as the hardware functions. 315 315 + 316 316 + % ============================================================ 317 317 + % 7. THE OPEN STACK 318 318 + % ============================================================ 319 319 + 320 320 + \section{The Open Stack} 321 321 + 322 322 + \subsection{Every Chromebook Is Already a Linux Machine} 323 323 + 324 324 + Here is the absurdity: every Chromebook already runs the Linux kernel. ChromeOS is Linux with a locked-down userspace that forces all interaction through Google's browser. The hardware is perfectly capable of running a free operating system. Google took a free kernel, wrapped it in proprietary restrictions, and sold it to schools as a cost-saving measure. 325 325 + 326 326 + The liberation of these machines does not require new hardware. It requires flashing new software. Many Chromebooks can be unlocked and reflashed with a standard Linux distribution or with \acos{}. The machine \emph{already wants to be free}. Google is the lock. 327 327 + 328 328 + \subsection{The IT Excuse} 329 329 + 330 330 + School IT departments choose Chromebooks because they are ``easy to manage.'' This is true. It is easy to manage a machine that does nothing. It is easy to administer a fleet when every device is a thin client for a single corporation's services. The ease of management is a direct consequence of the machine's powerlessness. 331 331 + 332 332 + The question is: easy for whom? Easy for the IT department, certainly. But catastrophic for the student. The IT department's convenience is purchased with the student's autonomy. This is a bad trade. 333 333 + 334 334 + Open-source management tools exist. NixOS provides reproducible system configurations. Ansible automates fleet deployment. PXE boot enables zero-touch provisioning. \acos{}~\citep{scudder2026acos} demonstrates that an entire OS can be deployed by flashing a USB drive in under a minute, with OTA updates requiring zero IT infrastructure. Penn Manor runs 1,725 Linux laptops with a smaller IT team than comparable Chromebook districts~\citep{pennmanor2024linux}. The ``management problem'' is solved. What remains is institutional inertia and a contractual relationship with Google that serves the institution, not the student. 335 335 + 336 336 + \subsection{The LLM Infrastructure} 337 337 + 338 338 + An open system enables a fundamentally different relationship with AI. A single surplus server (32--64\,GB RAM, or a used NVIDIA T4 GPU at \$100--200) can run Ollama and serve an entire classroom of students via Open WebUI---a free, open-source LLM frontend. Students connect from their laptops via a browser pointed at the local server. Models like Llama 3.2 3B (fits in 4\,GB), DeepSeek Coder 6.7B, or Qwen 2.5 Coder 7B provide strong code generation capability. 339 339 + 340 340 + This is local AI infrastructure that the school owns, that collects no telemetry, that sends no data to any corporation, and that students can inspect, modify, and learn from. The alternative---Google Gemini integrated into Workspace for Education---adds another layer of corporate dependency, another data pipeline, another subscription fee. 341 341 + 342 342 + % ============================================================ 343 343 + % 8. THE LLM GATEWAY 344 344 + % ============================================================ 345 345 + 346 346 + \section{The Student as Author} 347 347 + 348 348 + On an open system with LLM access, the student can: 349 349 + 350 350 + \begin{itemize} 351 351 + \item Ask the LLM to explain the operating system's source code 352 352 + \item Generate programs that run locally, with full hardware access 353 353 + \item Build web servers, databases, APIs---real infrastructure 354 354 + \item Create tools that solve real problems in their community 355 355 + \item Learn any programming language by building in it 356 356 + \item Understand the LLM itself by examining its inputs and outputs 357 357 + \item Create a piece on \ac{}~\citep{scudder2026ac} that anyone in the world can run 358 358 + \end{itemize} 359 359 + 360 360 + The LLM becomes a tutor with infinite patience, available 24 hours a day, that meets the student exactly where they are~\citep{khan2024bravenew}. But this tutor can only be effective if the student has a machine that can \emph{execute} what the tutor produces. 361 361 + 362 362 + The Chromebook model says: you are a user. The open model says: you are an author. In the age of LLMs, the difference between these two framings is the difference between digital literacy and digital serfdom. 363 363 + 364 364 + % ============================================================ 365 365 + % 9. A PATH FORWARD 366 366 + % ============================================================ 367 367 + 368 368 + \section{A Path Forward} 369 369 + 370 370 + \subsection{Phase 1: Awareness} 371 371 + 372 372 + Parents, teachers, and school board members must understand what a Chromebook actually is: a surveillance device that teaches learned helplessness. The first step is education---not of the children, but of the adults who purchase the machines. The EFF's ``Spying on Students'' documentation, the U.S. PIRG's ``Chromebook Churn'' report, and the New Mexico AG's lawsuit provide concrete evidence that can be presented at school board meetings. 373 373 + 374 374 + \subsection{Phase 2: Pilot Programs} 375 375 + 376 376 + School districts should pilot open-source alternatives, following Penn Manor's model: 377 377 + 378 378 + \begin{itemize} 379 379 + \item 30 surplus laptops running Linux or \acos{}, provisioned for \$3,000--5,400 380 380 + \item A local LLM server (one surplus workstation, \$200--500) running Ollama + Open WebUI 381 381 + \item An LLM-assisted curriculum where students build real software 382 382 + \item Student ownership: the machine goes home with the student 383 383 + \item A student-run repair program (Penn Manor's students fix their own machines) 384 384 + \item No cloud dependency: work is stored locally and backed up by the student 385 385 + \item Open assessment: the student's portfolio is code they wrote, tools they built, contributions they made 386 386 + \end{itemize} 387 387 + 388 388 + \subsection{Phase 3: Policy} 389 389 + 390 390 + States and districts should adopt policies requiring that: 391 391 + 392 392 + \begin{enumerate} 393 393 + \item All software deployed on student devices be open-source or source-available 394 394 + \item Students have root access to their own machines 395 395 + \item No behavioral telemetry is collected from student devices 396 396 + \item Students retain ownership of all work produced on school devices 397 397 + \item Graduating students keep their devices 398 398 + \item Device procurement prioritize refurbished hardware over new manufacturing 399 399 + \end{enumerate} 400 400 + 401 401 + Over 40 states have passed student data privacy laws. California's SOPIPA prohibits using student data for targeted advertising. The new COPPA rules (effective June 2025) strengthen children's data protections. These legislative trends support the case for open, non-surveilling school computing infrastructure. 402 402 + 403 403 + \subsection{Phase 4: Liberation} 404 404 + 405 405 + The endgame is not a policy change. It is a cultural shift. The endgame is a generation of students who understand that a computer is not a product they consume but an instrument they play---a medium for thought, creation, and contribution. Students who can read source code the way they read books. Students who can modify their tools the way a carpenter modifies a workbench. Students who see computation not as a corporate service but as a public commons to which they both contribute and belong. 406 406 + 407 407 + Nelson wrote in 1974~\citep{nelson1974computerlib}: ``You can and must understand computers NOW.'' Fifty years later, we have failed this imperative in precisely the way Nelson feared---by handing the machines to corporations and calling it progress. 408 408 + 409 409 + The LLM moment makes this failure visible. Every student now has the \emph{capability} to program. What they lack is a \emph{machine that lets them}. This is a solvable problem. The technology is free. The hardware is surplus. The only thing standing between every student and their own computational path is a corporate operating system that was never designed to serve them. 410 410 + 411 411 + % ============================================================ 412 412 + % 10. CONCLUSION 413 413 + % ============================================================ 414 414 + 415 415 + \section{Conclusion} 416 416 + 417 417 + Every Chromebook in every American school is a Linux machine in chains. The hardware can run a free operating system. The student can learn to program with an LLM. The surplus laptop market provides machines for \$100--180. The entire open-source stack is available at zero cost. Kerala has done it for 300,000 computers. Schleswig-Holstein has done it for 30,000. Penn Manor has done it for 1,725. It works. 418 418 + 419 419 + What we lack is not technology. We lack the political will to prioritize student autonomy over institutional convenience and corporate profit. 420 420 + 421 421 + Illich wrote that tools should expand personal autonomy rather than require specialized expertise~\citep{illich1973tools}. Papert wrote that computers should be instruments for thinking about thinking~\citep{papert1980mindstorms}. Stallman wrote that users deserve to control the software they run~\citep{stallman2002free}. Postman warned that technology in schools without purpose serves the technology, not the child~\citep{postman1995end}. These are not fringe positions. They are the founding principles of personal computing, and we have abandoned them in the one place they matter most: the education of children. 422 422 + 423 423 + Get closed source out of schools. Give every student a free and open operating system. Let the Chromebook be what it was always capable of being: not a gate, but a \emph{gateway}---to logic, creativity, community, spirituality, and every student's own path through the computational landscape. 424 424 + 425 425 + In the age of LLMs, this is not idealism. It is the minimum viable education. 426 426 + 427 427 + \vspace{0.5em} 428 428 + \noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913} 429 429 + 430 430 + \end{multicols} 431 431 + 432 432 + % ============================================================ 433 433 + % REFERENCES 434 434 + % ============================================================ 435 435 + 436 436 + \bibliographystyle{plainnat} 437 437 + \bibliography{references} 438 438 + 439 439 + \end{document}

+250

papers/arxiv-ucla-arts/ucla-arts-cards.tex

reviewed

··· 1 1 + % !TEX program = xelatex 2 2 + % Cards format — auto-generated from ucla-arts.tex by cards-convert.mjs 3 3 + \documentclass[11pt]{article} 4 4 + 5 5 + \usepackage{fontspec} 6 6 + \usepackage{unicode-math} 7 7 + \setmainfont{Latin Modern Roman} 8 8 + \setsansfont{Latin Modern Sans} 9 9 + \setmonofont{Latin Modern Mono}[Scale=0.88] 10 10 + 11 11 + 12 12 + \usepackage{graphicx} 13 13 + \graphicspath{{figures/}{../../papers/arxiv-ac/figures/}} 14 14 + \usepackage{booktabs} 15 15 + \usepackage{tabularx} 16 16 + \usepackage{ragged2e} 17 17 + \usepackage{microtype} 18 18 + \usepackage{natbib} 19 19 + 20 20 + 21 21 + 22 22 + \makeatletter 23 23 + \def\input@path{{../}} 24 24 + \makeatother 25 25 + \usepackage{ac-paper-cards} 26 26 + 27 27 + % Extra commands from base paper 28 28 + \newcommand{\dma}{\textsc{DMA}} 29 29 + \newcommand{\sofa}{\textsc{School of the Arts and Architecture}} 30 30 + 31 31 + \hypersetup{ 32 32 + pdftitle={Two Departments, One Building: Funding and Administration in UCLA Arts}, 33 33 + } 34 34 + 35 35 + \renewcommand{\acpdfbase}{ucla-arts-funding-26-arxiv} 36 36 + \begin{document} 37 37 + 38 38 + % ============================================================ 39 39 + % TITLE CARD 40 40 + % ============================================================ 41 41 + \thispagestyle{empty} 42 42 + \vspace*{\fill} 43 43 + \begin{center} 44 44 + \includegraphics[height=9em]{pals}\par\vspace{0.1em} 45 45 + {\acbold\fontsize{18pt}{22pt}\selectfont\color{acdark} Two Departments, One Building}\par 46 46 + \vspace{0.1em} 47 47 + {\fontsize{9pt}{11pt}\selectfont\color{acpink} Funding and Administration in UCLA Arts}\par 48 48 + \vspace{0.4em} 49 49 + {\normalsize\color{cyan!70!blue}\href{https://prompt.ac/@jeffrey}{\textbf{@jeffrey}}}\par 50 50 + {\small\color{acgray} Aesthetic.Computer}\par 51 51 + {\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par 52 52 + \vspace{0.4em} 53 53 + \rule{0.5\textwidth}{0.5pt}\par 54 54 + \vspace{0.15em} 55 55 + \colorbox{yellow!60}{\small\color{red!80!black}\textbf{\textit{working draft --- not for citation}}}\par 56 56 + \vspace{0.1em} 57 57 + {\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/894fbcb44}{894fbcb44}}\par 58 58 + \end{center} 59 59 + \vspace*{\fill} 60 60 + 61 61 + % ============================================================ 62 62 + % INDEX CARD 63 63 + % ============================================================ 64 64 + \cardindex 65 65 + 66 66 + % ============================================================ 67 67 + % BODY 68 68 + % ============================================================ 69 69 + \section{Introduction} 70 70 + 71 71 + Casey Reas co-created Processing in 2001 at MIT. He joined UCLA's Department of Design~|~Media Arts in 2004~\citep{dmahistory}. He chaired the department from 2007 to 2009. He co-founded the Processing Foundation as a 501(c)(3) in 2012. He receives zero dollars from the Foundation---per every IRS 990 filing on record. 72 72 + 73 73 + Lauren McCarthy created p5.js in 2013. She joined \dma{} as faculty. She spent the next decade maintaining it for 10--20 uncompensated hours per week on top of her teaching load~\citep{mccarthy2023making}. She also receives zero dollars from the Processing Foundation. 74 74 + 75 75 + Both are tenured professors. Both are paid by UCLA to teach and do research. The tools they built---used by millions---are subsidized by those salaries in a way that appears nowhere in any budget line. This is the model I described in ``Who Pays for Creative Tools?''~\citep{scudder2026sustainability} as \emph{academic subsidy}: the university pays for one thing, and the faculty member does another thing on top of it, and the second thing is what changes the world. 76 76 + 77 77 + This paper is about the institution that provides that subsidy. Not UCLA as a monolith, but two specific departments within one school---Art and \dma{}---that sit in the same Richard Meier building, report to the same dean, draw from the same \$70 million school operating budget, and operate with fundamentally different financial architectures. 78 78 + 79 79 + I am writing this as an outsider. I was invited to UCLA's Social Software lab as an Author in Residence for Spring 2026~\citep{scudder2026ac}. I build \ac{}, a creative computing platform, without the institutional umbrella that shelters Processing, p5.js, Scratch, Sonic Pi, and every other comparable tool in the field. Understanding how that umbrella works---and who holds it---is not academic curiosity. It is survival research. 80 80 + 81 81 + \section{Two Departments} 82 82 + 83 83 + \subsection{Art (1939--)} 84 84 + 85 85 + The Department of Art is the older sibling. Founded in 1939 within the College of Applied Arts, it was the first time students could major in art at UCLA. It moved through the College of Fine Arts (1960) and into the School of the Arts (1991, later \sofa{}). Its focus is studio fine art: painting, drawing, sculpture, photography, ceramics, printmaking, new genres, interdisciplinary studio. 86 86 + 87 87 + Its faculty roster reads like a museum collection catalog. Catherine Opie (photography), Andrea Fraser (interdisciplinary studio, current chair), Barbara Kruger (new genres, Distinguished Professor), Lari Pittman (painting, Distinguished Professor). These are artists whose work sells at auction, hangs in permanent collections, and defines entire movements. 88 88 + 89 89 + \subsection{Design~|~Media Arts (1988--)} 90 90 + 91 91 + \dma{} split from Art in 1988 as the Department of Design. The original focus was ceramics, textiles, industrial design, and graphic design. Rebecca Allen became chair in 1996 and pivoted toward media. In 2000 the department renamed itself Design~|~Media Arts. Erkki Huhtamo and Christian Moeller joined the faculty. Casey Reas arrived in 2004. 92 92 + 93 93 + Today \dma{} covers creative coding, graphic design, games, VR/AR, digital fabrication, and media theory. Its faculty builds software that runs on millions of machines. Its graduates work at Google, Apple, and Pixar---but also at small studios, nonprofits, and independent practices. 94 94 + 95 95 + \subsection{Same Building, Different Worlds} 96 96 + 97 97 + Both departments moved into the Eli and Edythe Broad Art Center in 2006---a \$52 million building (including a \$23.2 million gift from the Broad Foundation) designed by Richard Meier. They share hallways, elevators, and a dean. They do not share a financial logic. 98 98 + 99 99 + \begin{table}[h] 100 100 + \small 101 101 + \centering 102 102 + \begin{tabularx}{\columnwidth}{lXX} 103 103 + \toprule 104 104 + & \textbf{Art} & \textbf{DMA} \\ 105 105 + \midrule 106 106 + Founded & 1939 & 1988 \\ 107 107 + Focus & Studio fine art & Media, code, design \\ 108 108 + MFA studios & Off-campus (Culver City) & On-campus (Broad) \\ 109 109 + Endowed chairs & Yes (Resnick) & None \\ 110 110 + Major gifts & \$20M Leavin, \$2.5M Resnick & Shared Broad building \\ 111 111 + Grant sources & NEA, foundations & NSF, Getty, Rockefeller \\ 112 112 + Software output & Minimal & Processing, p5.js, Game Lab \\ 113 113 + \bottomrule 114 114 + \end{tabularx} 115 115 + \caption{Structural comparison of UCLA Art and \dma{}.} 116 116 + \label{tab:comparison} 117 117 + \end{table} 118 118 + 119 119 + \section{How Art Gets Funded} 120 120 + 121 121 + \subsection{The Leavin Gift} 122 122 + 123 123 + In 2016, gallerist and alumna Margo Leavin donated \$20 million to UCLA's Department of Art---the largest single gift by an alumna to the arts in University of California history. The money funded the Margo Leavin Graduate Art Studios: a 48,000 square foot campus in Culver City, designed by Johnston Marklee, opened in 2019. MFA students now work in purpose-built studios with natural light, fabrication shops, and exhibition space. 124 124 + 125 125 + This is how fine art departments get funded. A gallerist who built her career selling the work of artists who teach at the school gives money back to the school that produces the next generation of artists whose work she might sell. The loop is closed. The incentives are aligned. The money is real. 126 126 + 127 127 + \subsection{The Resnick Endowment} 128 128 + 129 129 + Lynda and Stewart Resnick (Wonderful Company, FIJI Water, POM Wonderful) gave \$2 million to endow the Lynda and Stewart Resnick Endowed Professorship in Art---the department's first endowed chair. Catherine Opie was the inaugural holder. They also gave \$500,000 to renovate the undergraduate photography lab. 130 130 + 131 131 + An endowed chair is perpetual funding. The principal generates interest; the interest pays a salary supplement and research funds; the professor holds the title for life or until they leave. It is the most stable form of academic funding that exists. 132 132 + 133 133 + \subsection{The Pattern} 134 134 + 135 135 + Art's funding comes from collectors, gallerists, and philanthropists who participate in the art market. The department produces artists. The art market values the artists. The market participants give back. This is not a universal model---most art departments do not have Margo Leavin as an alumna---but where it works, it works durably. 136 136 + 137 137 + \section{How DMA Gets Funded} 138 138 + 139 139 + \subsection{Research Grants} 140 140 + 141 141 + \dma{} faculty fund their work through competitive external grants: 142 142 + 143 143 + \begin{itemize} 144 144 + \item \textbf{NSF}: \$1.3 million for a culture/creativity/technology innovation project (McCarthy as collaborator) 145 145 + \item \textbf{Getty Foundation}: Pacific Standard Time grants (Vesna and others) 146 146 + \item \textbf{Rockefeller Foundation}: New media fellowship (Eddo Stern) 147 147 + \item \textbf{Creative Capital}: Emerging fields grants (Stern, McCarthy) 148 148 + \item \textbf{Chancellor's Arts Initiative}: Internal UCLA grants, \$5K--\$15K per project; over \$550K awarded across four cycles since 2021 149 149 + \end{itemize} 150 150 + 151 151 + These grants are project-based and time-limited. They fund specific research for specific periods. When the grant ends, the funding ends. There is no endowment. There is no perpetual interest. There is another application. 152 152 + 153 153 + \subsection{Six Initiatives, Six Directors} 154 154 + 155 155 + \dma{} currently operates six named research initiatives, each with its own director and distinct funding relationships: 156 156 + 157 157 + \begin{enumerate} 158 158 + \item \textbf{Social Software} (Reas + McCarthy)---software as culture, open source, AI. Partners: Processing Foundation, UCLA DataX, YoungArts. 159 159 + \item \textbf{UCLA Game Lab} (Eddo Stern)---cross-school, co-funded by Arts \& Architecture and Theater, Film \& Television. 160 160 + \item \textbf{Art|Sci Center} (Victoria Vesna)---art + nanoscience, jointly housed in \dma{} and the California NanoSystems Institute. Funded by NSF, Burroughs Wellcome Fund, Getty. 161 161 + \item \textbf{Conditional Studio} (Chandler McWilliams)---materiality of computation. 162 162 + \item \textbf{Counterforce Lab} (Rebeca Mendez). 163 163 + \item \textbf{MARS} (Romi Morrison). 164 164 + \end{enumerate} 165 165 + 166 166 + Each initiative is a funding island. The Game Lab works because two schools split the cost. Art|Sci works because a nanoscience institute co-hosts it. Social Software works because Reas and McCarthy bring their own institutional gravity. None of these arrangements is guaranteed to survive a leadership change, a budget cut, or a dean who prioritizes differently. 167 167 + 168 168 + \subsection{The Processing Foundation} 169 169 + 170 170 + The Processing Foundation is a 501(c)(3) nonprofit incorporated in Brooklyn, New York. It is not a UCLA entity. It receives no UCLA funding. Its board includes Reas and McCarthy, but the Foundation is institutionally independent. 171 171 + 172 172 + \begin{table}[h] 173 173 + \small 174 174 + \centering 175 175 + \begin{tabularx}{\columnwidth}{Xrrr} 176 176 + \toprule 177 177 + \textbf{Year} & \textbf{Revenue} & \textbf{Expenses} & \textbf{Assets} \\ 178 178 + \midrule 179 179 + 2020 & \$273K & \$182K & \$156K \\ 180 180 + 2021 & \$10.9M & \$430K & \$10.6M \\ 181 181 + 2022 & \$751K & \$647K & \$10.7M \\ 182 182 + 2023 & \$513K & \$1.23M & \$10.4M \\ 183 183 + 2024 & \$649K & \$1.52M & \$9.5M \\ 184 184 + \bottomrule 185 185 + \end{tabularx} 186 186 + \caption{Processing Foundation financials (IRS 990 filings via ProPublica).} 187 187 + \label{tab:pf-financials} 188 188 + \end{table} 189 189 + 190 190 + The 2021 spike---from \$273K to \$10.9 million in one year---was almost entirely cryptocurrency donations from generative artists during the NFT boom. Major donors included Erick Calderon (Art Blocks founder), Tyler Hobbs, Casey Reas himself, Monica Rizzolli, and Dmitri Cherniak. This was not a funding model. It was a weather event. It will not repeat. 191 191 + 192 192 + The Foundation is now spending approximately \$1.5 million per year against \$650K--\$970K in revenue, drawing down the 2021 reserves. At current burn rate, leadership estimates a 12--13 year runway. Reas, Fry, and Shiffman---the three co-founders---have received \$0 in compensation from the Foundation in every year on record. 193 193 + 194 194 + \subsection{The Invisible Subsidy} 195 195 + 196 196 + Here is what actually funds Processing and p5.js: UCLA pays Reas and McCarthy salaries. Those salaries buy them time. They spend some of that time---uncompensated, untracked, invisible to any budget---maintaining software used by millions. The Foundation exists to receive donations and coordinate development. UCLA exists to pay the salaries that make the unpaid work possible. 197 197 + 198 198 + This is the same pattern I documented across 28 tool authors in ``Who Pays''~\citep{scudder2026sustainability}. The university is the umbrella. The tool is the rain. The umbrella does not know it is holding off rain; it thinks it is employing a professor. 199 199 + 200 200 + \section{What the Art Market Funds vs.\ What Grants Fund} 201 201 + 202 202 + The distinction between Art and \dma{}'s funding models maps onto a deeper difference in what each department produces and who values it. 203 203 + 204 204 + Art produces \emph{objects}. Paintings, sculptures, photographs, installations. These objects enter a market with established infrastructure: galleries, auction houses, collectors, museum acquisitions committees, art fairs. The market assigns prices. Prices generate wealth. Wealth flows back as philanthropy. Opie's photographs sell. Kruger's installations are commissioned. The department's prestige attracts donors who want their names on buildings and chairs. 205 205 + 206 206 + \dma{} produces \emph{tools and experiences}. Processing is not an object you can hang on a wall. p5.js is not an edition of 45. The UCLA Game Lab's experimental games are not sold at Art Basel. The output is software---free, open-source, used by millions, valued by no market. When Reas's artwork sells (his generative pieces are in the V\&A, LACMA, Centre Pompidou), that is his art practice, not his software practice. The two are related but financially separate. 207 207 + 208 208 + The art market can fund art departments because it can price art. No equivalent market prices open-source creative tools. The \$10.9 million that arrived at the Processing Foundation in 2021 came from a temporary speculative bubble in digital art, not from a sustainable market for the tools themselves. 209 209 + 210 210 + \section{Administration} 211 211 + 212 212 + \subsection{School-Level Governance} 213 213 + 214 214 + Both departments report to the Dean of the \sofa{}. The school's total operating budget is approximately \$70 million across four departments (Architecture and Urban Design, Art, \dma{}, World Arts and Cultures/Dance). Specific departmental budget breakdowns are not publicly available. 215 215 + 216 216 + The dean position is currently interim (Lionel Popkin). The school is conducting a search for a permanent dean. This matters because deans control resource allocation between departments, and the balance between a department that attracts \$20 million philanthropic gifts and one that attracts \$1.3 million NSF grants is a political question as much as an administrative one. 217 217 + 218 218 + \subsection{Faculty Lines} 219 219 + 220 220 + \dma{} currently has 15 faculty members (7 professors, 3 associate professors, 4 assistant professors, 1 research professor). Each faculty line represents a university commitment of \$150K--\$250K per year in salary and benefits. The six research initiatives are faculty-led---they exist because specific professors direct them, and they will need to be re-staffed or dissolved when those professors retire or leave. 221 221 + 222 222 + \subsection{Graduate Funding} 223 223 + 224 224 + Both departments offer 4--5 year funding packages for incoming MFA students, currently approximately \$30,000 per year plus tuition (combination of fellowships and TAships). Art's students work in the Leavin studios in Culver City. \dma{}'s students work in the Broad Art Center. The funding level is comparable; the physical infrastructure is not---Leavin's purpose-built facilities are a direct product of the \$20 million gift. 225 225 + 226 226 + \section{Implications for \ac{}} 227 227 + 228 228 + I build \ac{} without any of this. No UCLA salary. No NSF grants. No Processing Foundation reserves. No Margo Leavin writing a \$20 million check. No endowed chair generating perpetual interest. The companion paper~\citep{scudder2026sustainability} documents the full economic history. 229 229 + 230 230 + The UCLA model shows what institutional shelter looks like at its best: tenured faculty with time to build, research labs with named directors, external grants that fund specific projects, a school-level budget that keeps the lights on. It also shows the fragility: the Processing Foundation's reserves are finite, the grants are time-limited, the initiatives depend on specific people, and the open-source tools that reach the most users are the least funded part of the entire system. 231 231 + 232 232 + The question for \ac{} is not ``how do I get a UCLA salary?''---I don't, and probably won't. The question is whether the model that works for Processing and p5.js (invisible academic subsidy + a nonprofit foundation + a one-time crypto windfall) can be replicated, adapted, or replaced by something that doesn't require being a tenured professor at a research university. 233 233 + 234 234 + So far, the answer is: not obviously. But the attempt is the project. 235 235 + 236 236 + \section{Conclusion} 237 237 + 238 238 + UCLA's School of the Arts and Architecture houses two departments that represent two financial logics of contemporary creative practice. Art is funded by the art market---by collectors, gallerists, and philanthropists who participate in a pricing system for objects. \dma{} is funded by research grants, cross-institutional partnerships, and the invisible subsidy of faculty salaries applied to unpaid software work. 239 239 + 240 240 + Both models work, in the sense that both departments are functional and prestigious. Neither model funds open-source creative tools directly. Processing exists because Casey Reas has a UCLA salary and donates his own money to the Foundation he co-founded. p5.js exists because Lauren McCarthy has a UCLA salary and spends her evenings maintaining code. The \$10.9 million windfall that temporarily stabilized the Foundation came from a speculative bubble, not a sustainable market. 241 241 + 242 242 + The building is beautiful. The hallways are shared. The money flows through different pipes. 243 243 + 244 244 + \vspace{0.5em} 245 245 + \noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913} 246 246 + 247 247 + \bibliographystyle{plainnat} 248 248 + \bibliography{references} 249 249 + 250 250 + \end{document}

+5

papers/cards-convert.mjs

reviewed

··· 34 34 "arxiv-complex": { base: "complex", title: "Sucking on the Complex", siteName: "sucking-on-the-complex-26-arxiv" }, 35 35 "arxiv-kidlisp-cards": { base: "kidlisp-cards", title: "Kid{\\color{acpurple}Lisp} Cards", siteName: "kidlisp-cards-26-arxiv" }, 36 36 "arxiv-score-analysis": { base: "score-analysis", title: "Reading the Score", siteName: "reading-the-score-26-arxiv" }, 37 37 + "arxiv-calarts": { base: "calarts", title: "CalArts, Callouts, and Papers", siteName: "calarts-callouts-papers-26-arxiv" }, 38 38 + "arxiv-open-schools": { base: "open-schools", title: "Get Closed Source Out of Schools", siteName: "open-schools-26-arxiv" }, 39 39 + "arxiv-futures": { base: "futures", title: "Five Years from Now", siteName: "five-years-from-now-26-arxiv" }, 40 40 + "arxiv-identity": { base: "identity", title: "Handle Identity on the AT Protocol", siteName: "handle-identity-atproto-26-arxiv" }, 41 41 + "arxiv-ucla-arts": { base: "ucla-arts", title: "Two Departments, One Building", siteName: "ucla-arts-funding-26-arxiv" }, 37 42 }; 38 43 39 44 function extractFromTex(content) {

+8

papers/cli.mjs

reviewed

··· 175 175 siteName: "handle-identity-atproto-26-arxiv", 176 176 title: "Handle Identity on the AT Protocol", 177 177 }, 178 178 + "arxiv-ucla-arts": { 179 179 + base: "ucla-arts", 180 180 + siteName: "ucla-arts-funding-26-arxiv", 181 181 + title: "Two Departments, One Building", 182 182 + }, 178 183 }; 179 184 180 185 function texName(base, lang) { ··· 369 374 "citation-diversity-audit-26": 17, 370 375 "open-schools-26-arxiv": 18, 371 376 "five-years-from-now-26-arxiv": 19, 377 377 + "calarts-callouts-papers-26-arxiv": 20, 378 378 + "handle-identity-atproto-26-arxiv": 21, 379 379 + "ucla-arts-funding-26-arxiv": 22, 372 380 }; 373 381 374 382 // Collect deployed English PDFs sorted by importance