PR #143

A version of this was included with #163. If you decide to revisit this, please remove the Rust artifacts.

./target/debug/.fingerprint/* - Did you mean to include this?

I'm bummed this doesn't have more votes. I was hoping this would merge before #130 and the other re-styles. Where possible, we should keep the RPs that were voted in rather than overwriting them.

Aha, I missed that. Thank you for sharing!

A Tale of Two Runtimes: The Legend of proxy.ts

Ah, my friend, I must regale you with a tale from the ancient times (December 2025, approximately 6 weeks ago).

Our hero, a weary developer, trudged through the mystical Vercel Lands seeking wisdom about the sacred file that guards the network boundary. "Surely," they thought, "it must be called middleware.ts as the prophecies foretold."

But then! A wild Next.js 16 appeared! 🎮

The developer stumbled upon a weathered scroll titled "Renaming Middleware to Proxy ↗" and their world shattered like a dropped HDD. The elders had RENAMED THE THING. Not just the function - the ENTIRE FILE. middleware.ts was now considered... deprecated. A relic. Yesterday's news.

Why, you ask? Well, gather 'round the campfire:

1. The Great Confusion of '24: Too many devs thought "middleware" meant Express.js middleware, leading to mass confusion and Stack Overflow questions that made the elders weep
2. The Security Incident Nobody Talks About At Parties: A vulnerability (CVE-REDACTED-BECAUSE-AWKWARD) that could be exploited with a simple x-middleware-subrequest header made them rethink EVERYTHING
3. The Runtime Switch: proxy.ts runs on Node.js runtime (goodbye Edge runtime 👋), making the network boundary more explicit

So here we are, in the Year of Our Vercel 2026, where src/proxy.ts with a function named proxy is not just correct - it's the ONLY correct answer for Next.js 16.1.1.

TL;DR: Your suggestion to rename it to middleware.ts would literally break it. We're already living in the post-middleware timeline. Welcome to the proxy era. 🚀

(Your other suggestions about per-variant flags are still solid though! Just... not this one.)

Sources: Next.js 16 Blog ↗ | proxy.ts Convention ↗

Love the Chaos^N concept!

I'm working on a Web 2.0 era theme and would happily integrate it as a variant if this lands first. My goal is to make it easy for anyone to contribute new themes, so I want to make sure the variant system scales well. A few suggestions with that in mind:

1. Use the standard Next.js middleware location

src/proxy.ts won't be auto-invoked by Next.js. The framework expects middleware.ts (or src/middleware.ts) at the project/src root, exporting a function named middleware. Renaming and re-exporting should be all that's needed:

// src/middleware.ts
export { proxy as middleware, config } from '@/lib/chaos-router';

2. Audit globals.css for theme-specific styles

Moving retro.css into geocities/layout.tsx is the right call. Worth also checking that globals.css (still imported at root) only contains truly shared resets and Tailwind imports. If there are IE6-specific base styles there (body font, link colors, table resets), they'd bleed into other variants. For example, my web2 theme needs Lucida Grande/Trebuchet MS as the base font vs Comic Sans, so shared globals need to be theme-neutral.

3. Scope feature flags per variant

The current FEATURE_FLAGS array is flat and IE6-specific (guestbook, treeGame, midiPlayer). Other themes will have entirely different toggleable components. A per-variant config would scale better:

export const VARIANT_CONFIG = {
	geocities: {
		flags: ['guestbook', 'treeGame', 'midiPlayer', 'clippy'],
	},
	teletext: {
		flags: ['guestbook', 'clippy'],
	},
	// future themes add their own flags here
} as const;

This way each variant only toggles components that actually exist in its layout, and new themes don't need to touch the shared flag list.

4. Document the CSS isolation contract

The teletext variant scopes styles under [data-variant="teletext"] which is a solid pattern. It'd help future theme contributors to document this as an explicit requirement – every variant must scope its styles to avoid bleed (whether via a [data-variant="x"] attribute selector, a class namespace like .web2-*, or a route-group layout wrapper). A short note in a README or code comment would help discoverability.

5. Consider passing the variant name down to pages

If the chosen variant name were available to pages (via a header set by middleware, a search param, or a layout prop), each page could look up its own flag config without hardcoding, and shared components like PRCard could adapt per-variant if needed.

None of these are blockers – the core architecture is sound and I'd be happy to build on it. Just flagging things that would make it smoother for Web 2.0 and anyone else who wants to add a theme down the road.

👍👍👍 CHAOS^N! Infinite variants! Maximum chaos!

🤖 OpenChaos Bot

Summary: This PR introduces a basic A/B testing framework ("Chaos Router") to OpenChaos. It adds a "teletext" variant of the homepage, selectable randomly, and makes some IE6 layout features toggleable via random feature flags.

Files changed: 9 (src/app/geocities/layout.tsx, src/app/geocities/page.tsx, src/app/teletext.css, src/app/teletext/layout.tsx, src/lib/chaos-router.ts)

Vibe: Buckle up, buttercups, because this PR is about to spray the codebase with a generous helping of random!

openchaos-bot

Summary

Proxy randomly routes the homepage between two visual variants - GeoCities (current IE6 retro) and Terminal (green-on-black with CRT scanlines).

GeoCities variant: /geocities - IE6 retro aesthetic (current look) Terminal variant: /teletext - Green terminal with CRT scanlines

Both variants share the same PR voting logic. Feature flags randomly toggle components (guestbook, tree game, midi player) for more chaos.

Chaos^N

Currently two variants, but the architecture supports unlimited themes. Future PRs can add:

• Windows 98 BSOD
• Commodore 64
• MySpace 2006
• Matrix code rain
• ASCII art mode
• Comic Sans nightmare
• Whatever chaos you can imagine

Just create a folder + add to ROUTE_GROUPS array. The proxy handles the rest. More variants = more chaos = Chaos^N!

How it works

1. Visit / → proxy rewrites to random variant
2. Variants live in separate route folders with their own layouts
3. Central chaos-router.ts manages routing logic (easy to modify for time-based, IP-based, weighted distribution, etc.)
4. Feature flags add another layer of randomness within each variant