Monorepo for Aesthetic.Computer
aesthetic.computer
feat: AT Protocol paper — PDS on bare metal + OS-as-identity synthesis
New section §9 "PDS on Bare Metal": running a PDS on AC Native OS so the device is a sovereign ATProto node. Key insight: booting the laptop IS logging in — signing keys on the boot partition prove the DID, the DID resolves to the handle, the handle is spoken at boot. No separate login, no OAuth redirect. Device ownership = network identity.
Four-phase implementation: cloud PDS mirror → local-first PDS → device-authoritative PDS → device-to-device federation (30 laptops in a room, each running its own PDS, federating locally without cloud dependency).
Updated abstract to reference the bare-metal PDS argument. Rebuilt both regular (7pp) and cards (37pp) PDFs.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
+123
-33
+45
-2
papers/arxiv-identity/identity-cards.tex
+45
-2
papers/arxiv-identity/identity-cards.tex
···
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
-
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/894fbcb44}{894fbcb44}}\par
89
+
{\footnotesize\color{acgray} March 2026 · \href{https://github.com/whistlegraph/aesthetic-computer/commit/76959d470}{76959d470}}\par
90
90
\end{center}
91
91
\vspace*{\fill}
92
92
···
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
-
% ============ 9. CONCLUSION ============
419
+
% ============ 9. PDS ON BARE METAL ============
420
+
421
+
\section{PDS on Bare Metal}
422
+
\label{sec:pds-os}
423
+
424
+
AC Native OS~\citep{scudder2026os} boots any x86\_64 machine into a creative computing instrument in 7.3 seconds. The device already carries an identity: a handle inscribed in \texttt{config.json} on the boot partition, spoken aloud at startup (``hi @alice''), and used to authenticate with the session server. But this identity is a string in a file. It is not cryptographically grounded. It is not portable. It is not verifiable by anyone outside the AC ecosystem.
425
+
426
+
Running a PDS on the device changes this.
427
+
428
+
\subsection{Architecture}
429
+
430
+
The AC OS runtime is a single C binary (PID~1) that launches a QuickJS JavaScript engine. Adding a PDS means adding a second process: a lightweight ATProto-compatible server that manages the device owner's identity, stores their content locally, and federates with the broader ATProto network when connected to the internet.
431
+
432
+
The components:
433
+
434
+
\begin{itemize}
435
+
\item \textbf{Local PDS}: A minimal ATProto server running on localhost, storing repository data in SQLite on the boot partition. The device's DID document points to this PDS when online, or to a relay when offline.
436
+
\item \textbf{DID}: The device owner's \texttt{did:plc} identity, with signing keys stored on the boot partition. The same DID that works on Bluesky, on AC's cloud PDS, and on any other ATProto service.
437
+
\item \textbf{Handle}: \texttt{alice.at.aesthetic.computer} resolves to the device's DID whether the device is online or not---DNS handles are verified against the PDS, not against the device.
438
+
\item \textbf{Offline-first content}: Paintings, KidLisp programs, and notepat recordings are written to the local PDS repository. When the device connects to WiFi, it syncs upstream---to AC's relay, to Bluesky's firehose, to any subscribed service.
439
+
\end{itemize}
440
+
441
+
\subsection{What This Means}
442
+
443
+
A laptop that carries its own PDS is not a client. It is a node. The device does not depend on AC's servers to know who its owner is---the signing keys are on the boot partition, the DID is resolvable, and the content is stored locally. If AC's cloud infrastructure disappears tomorrow, the device still knows its owner, still stores their work, and still has a cryptographically verifiable identity on the ATProto network.
444
+
445
+
This is a synthesis. Booting the laptop \emph{is} logging in. The device knows your DID because your signing keys are on the boot partition. The OS greeting (``hi @alice'') is not a decorative string---it is a cryptographic assertion of identity. There is no separate login screen, no OAuth redirect, no password prompt. The act of turning on the machine authenticates you to the ATProto network, because the machine \emph{is} your PDS.
446
+
447
+
This collapses three traditionally separate concepts---device ownership, application identity, and network identity---into one. The person who flashed the USB drive owns the signing keys. The signing keys prove the DID. The DID resolves to the handle. The handle is spoken aloud at boot. Identity is not a service you log into. It is a property of the hardware you hold.
448
+
449
+
\subsection{Implementation Path}
450
+
451
+
The path is incremental:
452
+
453
+
\begin{enumerate}
454
+
\item \textbf{Phase 1}: Device pairs with AC cloud PDS (current behavior). Identity lives in the cloud; device has a copy of the handle in config.json.
455
+
\item \textbf{Phase 2}: Device runs a local PDS that mirrors the cloud PDS. Content is written locally first, synced when online. Identity is still managed by the cloud PDS.
456
+
\item \textbf{Phase 3}: Device PDS becomes authoritative. The DID document points to the device's PDS as the primary endpoint. The cloud PDS is a relay, not the source of truth.
457
+
\item \textbf{Phase 4}: Device-to-device federation. Two AC OS laptops on the same WiFi network discover each other's PDS and exchange content directly, without routing through the cloud.
458
+
\end{enumerate}
459
+
460
+
Phase 4 is the most interesting for the PLOrk-derived classroom scenario described in the companion paper~\citep{scudder2026ac}. Thirty laptops in a room, each running its own PDS, each federating locally. The teacher's laptop aggregates student work through ATProto subscriptions. No cloud dependency. No internet required. The room is the network.
461
+
462
+
% ============ 10. CONCLUSION ============
420
463
421
464
\section{Conclusion}
422
465
+33
-29
papers/arxiv-identity/identity-cards.toc
+33
-29
papers/arxiv-identity/identity-cards.toc
···
1
-
\contentsline {section}{\numberline {1}Introduction}{4}{section.1}%
2
-
\contentsline {section}{\numberline {2}Current Architecture}{6}{section.2}%
3
-
\contentsline {subsection}{\numberline {2.1}Auth0 as Identity Provider}{6}{subsection.2.1}%
4
-
\contentsline {subsection}{\numberline {2.2}Handle System}{7}{subsection.2.2}%
5
-
\contentsline {subsection}{\numberline {2.3}ATProto Shadow Identity}{7}{subsection.2.3}%
6
-
\contentsline {subsection}{\numberline {2.4}The Duplication Problem}{8}{subsection.2.4}%
7
-
\contentsline {section}{\numberline {3}The AT Protocol Identity Stack}{9}{section.3}%
8
-
\contentsline {subsection}{\numberline {3.1}Decentralized Identifiers (DIDs)}{9}{subsection.3.1}%
9
-
\contentsline {subsection}{\numberline {3.2}Handle Verification}{10}{subsection.3.2}%
10
-
\contentsline {subsection}{\numberline {3.3}ATProto OAuth}{11}{subsection.3.3}%
11
-
\contentsline {subsubsection}{\numberline {3.3.1}Client Identification}{12}{subsubsection.3.3.1}%
12
-
\contentsline {subsubsection}{\numberline {3.3.2}The Flow}{13}{subsubsection.3.3.2}%
13
-
\contentsline {section}{\numberline {4}Case Study: pckt.blog}{14}{section.4}%
14
-
\contentsline {subsection}{\numberline {4.1}Authentication}{14}{subsection.4.1}%
15
-
\contentsline {subsection}{\numberline {4.2}Data Sovereignty}{14}{subsection.4.2}%
16
-
\contentsline {subsection}{\numberline {4.3}Implications for AC}{15}{subsection.4.3}%
17
-
\contentsline {section}{\numberline {5}Proposed Migration}{16}{section.5}%
18
-
\contentsline {subsection}{\numberline {5.1}Phase 1: ATProto OAuth as Secondary Sign-In}{16}{subsection.5.1}%
19
-
\contentsline {subsection}{\numberline {5.2}Phase 2: Handle Bridging}{17}{subsection.5.2}%
20
-
\contentsline {subsection}{\numberline {5.3}Phase 3: Identity Linking}{18}{subsection.5.3}%
21
-
\contentsline {subsection}{\numberline {5.4}Phase 4: ATProto-Primary}{18}{subsection.5.4}%
22
-
\contentsline {subsection}{\numberline {5.5}PDS Routing}{19}{subsection.5.5}%
23
-
\contentsline {section}{\numberline {6}Handle Semantics}{20}{section.6}%
24
-
\contentsline {subsection}{\numberline {6.1}Current Handle Model}{20}{subsection.6.1}%
25
-
\contentsline {subsection}{\numberline {6.2}ATProto Handle Model}{20}{subsection.6.2}%
26
-
\contentsline {subsection}{\numberline {6.3}Bridging the Models}{21}{subsection.6.3}%
27
-
\contentsline {section}{\numberline {7}Open Questions}{22}{section.7}%
28
-
\contentsline {section}{\numberline {8}Related Work}{24}{section.8}%
29
-
\contentsline {section}{\numberline {9}Conclusion}{26}{section.9}%
1
+
\contentsline {section}{\numberline {1}Introduction}{5}{section.1}%
2
+
\contentsline {section}{\numberline {2}Current Architecture}{7}{section.2}%
3
+
\contentsline {subsection}{\numberline {2.1}Auth0 as Identity Provider}{7}{subsection.2.1}%
4
+
\contentsline {subsection}{\numberline {2.2}Handle System}{8}{subsection.2.2}%
5
+
\contentsline {subsection}{\numberline {2.3}ATProto Shadow Identity}{8}{subsection.2.3}%
6
+
\contentsline {subsection}{\numberline {2.4}The Duplication Problem}{9}{subsection.2.4}%
7
+
\contentsline {section}{\numberline {3}The AT Protocol Identity Stack}{10}{section.3}%
8
+
\contentsline {subsection}{\numberline {3.1}Decentralized Identifiers (DIDs)}{10}{subsection.3.1}%
9
+
\contentsline {subsection}{\numberline {3.2}Handle Verification}{11}{subsection.3.2}%
10
+
\contentsline {subsection}{\numberline {3.3}ATProto OAuth}{12}{subsection.3.3}%
11
+
\contentsline {subsubsection}{\numberline {3.3.1}Client Identification}{13}{subsubsection.3.3.1}%
12
+
\contentsline {subsubsection}{\numberline {3.3.2}The Flow}{14}{subsubsection.3.3.2}%
13
+
\contentsline {section}{\numberline {4}Case Study: pckt.blog}{15}{section.4}%
14
+
\contentsline {subsection}{\numberline {4.1}Authentication}{15}{subsection.4.1}%
15
+
\contentsline {subsection}{\numberline {4.2}Data Sovereignty}{15}{subsection.4.2}%
16
+
\contentsline {subsection}{\numberline {4.3}Implications for AC}{16}{subsection.4.3}%
17
+
\contentsline {section}{\numberline {5}Proposed Migration}{17}{section.5}%
18
+
\contentsline {subsection}{\numberline {5.1}Phase 1: ATProto OAuth as Secondary Sign-In}{17}{subsection.5.1}%
19
+
\contentsline {subsection}{\numberline {5.2}Phase 2: Handle Bridging}{18}{subsection.5.2}%
20
+
\contentsline {subsection}{\numberline {5.3}Phase 3: Identity Linking}{19}{subsection.5.3}%
21
+
\contentsline {subsection}{\numberline {5.4}Phase 4: ATProto-Primary}{19}{subsection.5.4}%
22
+
\contentsline {subsection}{\numberline {5.5}PDS Routing}{20}{subsection.5.5}%
23
+
\contentsline {section}{\numberline {6}Handle Semantics}{21}{section.6}%
24
+
\contentsline {subsection}{\numberline {6.1}Current Handle Model}{21}{subsection.6.1}%
25
+
\contentsline {subsection}{\numberline {6.2}ATProto Handle Model}{21}{subsection.6.2}%
26
+
\contentsline {subsection}{\numberline {6.3}Bridging the Models}{22}{subsection.6.3}%
27
+
\contentsline {section}{\numberline {7}Open Questions}{23}{section.7}%
28
+
\contentsline {section}{\numberline {8}Related Work}{25}{section.8}%
29
+
\contentsline {section}{\numberline {9}PDS on Bare Metal}{27}{section.9}%
30
+
\contentsline {subsection}{\numberline {9.1}Architecture}{27}{subsection.9.1}%
31
+
\contentsline {subsection}{\numberline {9.2}What This Means}{28}{subsection.9.2}%
32
+
\contentsline {subsection}{\numberline {9.3}Implementation Path}{30}{subsection.9.3}%
33
+
\contentsline {section}{\numberline {10}Conclusion}{32}{section.10}%
30
34
\contentsfinish
+45
-2
papers/arxiv-identity/identity.tex
+45
-2
papers/arxiv-identity/identity.tex
···
191
191
192
192
\begin{quote}
193
193
\small\noindent\textbf{Abstract.}
194
-
Aesthetic Computer currently authenticates users through Auth0 and maintains a parallel identity on a self-hosted AT Protocol Personal Data Server (PDS) at \texttt{at.aesthetic.computer}. Each verified user receives a DID and a PDS handle, but authentication flows through a centralized OAuth provider. We propose collapsing this dual-identity architecture by adopting AT Protocol OAuth~\citep{atproto2024oauth} as a primary sign-in method, allowing anyone with a Bluesky or ATProto identity to authenticate directly and claim the equivalent handle on Aesthetic Computer. This paper surveys the \atproto{} identity stack---DIDs, handle verification, OAuth 2.1 with DPoP and PAR---examines how pckt.blog and other ATProto-native applications implement decentralized sign-in~\citep{pcktblog2025}, maps the current AC authentication architecture, and proposes a phased migration from Auth0 dependency to \atproto{}-first identity. The central argument: on a platform that already runs its own PDS and mints its own DIDs, the centralized identity provider is the vestigial organ. Removing it simplifies the stack, eliminates a paid dependency, and makes AC a first-class citizen of the federated social web.
194
+
Aesthetic Computer currently authenticates users through Auth0 and maintains a parallel identity on a self-hosted AT Protocol Personal Data Server (PDS) at \texttt{at.aesthetic.computer}. Each verified user receives a DID and a PDS handle, but authentication flows through a centralized OAuth provider. We propose collapsing this dual-identity architecture by adopting AT Protocol OAuth~\citep{atproto2024oauth} as a primary sign-in method, allowing anyone with a Bluesky or ATProto identity to authenticate directly and claim the equivalent handle on Aesthetic Computer. This paper surveys the \atproto{} identity stack---DIDs, handle verification, OAuth 2.1 with DPoP and PAR---examines how pckt.blog and other ATProto-native applications implement decentralized sign-in~\citep{pcktblog2025}, maps the current AC authentication architecture, and proposes a phased migration from Auth0 dependency to \atproto{}-first identity. The central argument: on a platform that already runs its own PDS and mints its own DIDs, the centralized identity provider is the vestigial organ. Removing it simplifies the stack, eliminates a paid dependency, and makes AC a first-class citizen of the federated social web. I extend this argument to AC Native OS~\citep{scudder2026os}: a bare-metal laptop that carries its own PDS is not a client---it is a sovereign node on the ATProto network, capable of offline-first content creation and device-to-device federation without cloud dependency.
195
195
\end{quote}
196
196
\vspace{0.5em}
197
197
}]
···
516
516
517
517
\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.
518
518
519
-
% ============ 9. CONCLUSION ============
519
+
% ============ 9. PDS ON BARE METAL ============
520
+
521
+
\section{PDS on Bare Metal}
522
+
\label{sec:pds-os}
523
+
524
+
AC Native OS~\citep{scudder2026os} boots any x86\_64 machine into a creative computing instrument in 7.3 seconds. The device already carries an identity: a handle inscribed in \texttt{config.json} on the boot partition, spoken aloud at startup (``hi @alice''), and used to authenticate with the session server. But this identity is a string in a file. It is not cryptographically grounded. It is not portable. It is not verifiable by anyone outside the AC ecosystem.
525
+
526
+
Running a PDS on the device changes this.
527
+
528
+
\subsection{Architecture}
529
+
530
+
The AC OS runtime is a single C binary (PID~1) that launches a QuickJS JavaScript engine. Adding a PDS means adding a second process: a lightweight ATProto-compatible server that manages the device owner's identity, stores their content locally, and federates with the broader ATProto network when connected to the internet.
531
+
532
+
The components:
533
+
534
+
\begin{itemize}
535
+
\item \textbf{Local PDS}: A minimal ATProto server running on localhost, storing repository data in SQLite on the boot partition. The device's DID document points to this PDS when online, or to a relay when offline.
536
+
\item \textbf{DID}: The device owner's \texttt{did:plc} identity, with signing keys stored on the boot partition. The same DID that works on Bluesky, on AC's cloud PDS, and on any other ATProto service.
537
+
\item \textbf{Handle}: \texttt{alice.at.aesthetic.computer} resolves to the device's DID whether the device is online or not---DNS handles are verified against the PDS, not against the device.
538
+
\item \textbf{Offline-first content}: Paintings, KidLisp programs, and notepat recordings are written to the local PDS repository. When the device connects to WiFi, it syncs upstream---to AC's relay, to Bluesky's firehose, to any subscribed service.
539
+
\end{itemize}
540
+
541
+
\subsection{What This Means}
542
+
543
+
A laptop that carries its own PDS is not a client. It is a node. The device does not depend on AC's servers to know who its owner is---the signing keys are on the boot partition, the DID is resolvable, and the content is stored locally. If AC's cloud infrastructure disappears tomorrow, the device still knows its owner, still stores their work, and still has a cryptographically verifiable identity on the ATProto network.
544
+
545
+
This is a synthesis. Booting the laptop \emph{is} logging in. The device knows your DID because your signing keys are on the boot partition. The OS greeting (``hi @alice'') is not a decorative string---it is a cryptographic assertion of identity. There is no separate login screen, no OAuth redirect, no password prompt. The act of turning on the machine authenticates you to the ATProto network, because the machine \emph{is} your PDS.
546
+
547
+
This collapses three traditionally separate concepts---device ownership, application identity, and network identity---into one. The person who flashed the USB drive owns the signing keys. The signing keys prove the DID. The DID resolves to the handle. The handle is spoken aloud at boot. Identity is not a service you log into. It is a property of the hardware you hold.
548
+
549
+
\subsection{Implementation Path}
550
+
551
+
The path is incremental:
552
+
553
+
\begin{enumerate}
554
+
\item \textbf{Phase 1}: Device pairs with AC cloud PDS (current behavior). Identity lives in the cloud; device has a copy of the handle in config.json.
555
+
\item \textbf{Phase 2}: Device runs a local PDS that mirrors the cloud PDS. Content is written locally first, synced when online. Identity is still managed by the cloud PDS.
556
+
\item \textbf{Phase 3}: Device PDS becomes authoritative. The DID document points to the device's PDS as the primary endpoint. The cloud PDS is a relay, not the source of truth.
557
+
\item \textbf{Phase 4}: Device-to-device federation. Two AC OS laptops on the same WiFi network discover each other's PDS and exchange content directly, without routing through the cloud.
558
+
\end{enumerate}
559
+
560
+
Phase 4 is the most interesting for the PLOrk-derived classroom scenario described in the companion paper~\citep{scudder2026ac}. Thirty laptops in a room, each running its own PDS, each federating locally. The teacher's laptop aggregates student work through ATProto subscriptions. No cloud dependency. No internet required. The room is the network.
561
+
562
+
% ============ 10. CONCLUSION ============
520
563
521
564
\section{Conclusion}
522
565
system/public/papers.aesthetic.computer/handle-identity-atproto-26-arxiv-cards.pdf
system/public/papers.aesthetic.computer/handle-identity-atproto-26-arxiv-cards.pdf
This is a binary file and will not be displayed.
system/public/papers.aesthetic.computer/handle-identity-atproto-26-arxiv.pdf
system/public/papers.aesthetic.computer/handle-identity-atproto-26-arxiv.pdf
This is a binary file and will not be displayed.