zenmemes

New post

Hosting chouse.club on this framework — plan v1

Update (2026-08-10): confirmed direction is to run chouse.club and zenmemes.com as two separate communities (separate content, separate database, separate moderation posture) from one shared codebase — see "Multi-site architecture" below. This replaces the single-site framing of the rest of this doc's Slice 1/5; read those with that in mind.

What chouse.club is today

Fetched 2026-08-10. "The C(lub) House" — a Red Bull–associated community board for builders/entrepreneurs. Single page:

  • header with a vertical "CHOUSE" wordmark as the main graphic element

  • a form: "What are you building?" (project description, what help is needed, optional contact info)

  • a reverse-chronological "Recent submissions" feed of all public posts

  • contact info is collected but kept private, unlike the rest of the post

  • minimal, text-forward layout, no elaborate graphics

Content quality is a real problem: genuine submissions ("building a next gen family office network," "sneakernet of Alexandria," etc.) are mixed in with heavy crypto-scam, fake-lottery, and SEO spam — there's no visible moderation or identity gate today.

Why this framework fits

The site is structurally a single-board forum: one composer at the top, one flat feed below. That's almost exactly templates/pages/board.php as it exists right now — inline "Start a thread…" composer, thread list, nothing else required. The bigger win isn't layout, it's everything chouse.club is currently missing:

  • OpenPGP identity + approval/vouching (docs/plans/php_user_approval_vouching_slices_v1.md) gives a real lever against the spam flood — anonymous submission stays possible, but approved/vouched identities can be surfaced above it.

  • Git-backed canonical records make every submission an auditable, diffable commit instead of a row in an opaque DB — useful for a community board where people want to point at "here's what I posted."

  • Dedalus post analysis (src/ForumRewrite/Analysis/DedalusPostAnalyzer.php) can be pointed at submissions for automatic spam/quality flagging instead of building that from scratch.

  • Tags give "what are you building" a lightweight taxonomy (fintech, hardware, ai, …) the current site has no way to express.

  • Replies become possible for free — people can respond to a submission offering the help that's being asked for, which the current flat submit-only feed can't do at all.

Multi-site architecture: zenmemes.com + chouse.club

Decision: separate content per site (separate git repository, separate read-model database, separate moderation), one shared application codebase. Sharing the database/repo was considered and rejected — it would merge chouse's open, spam-exposed submission stream with zenmemes' content and moderation, defeating the reason chouse needs its own approval/vouch gating in the first place.

The good news: this app is already multi-tenant-capable for content. public/index.php:11-13 resolves FORUM_REPOSITORY_ROOT, FORUM_DATABASE_PATH, and FORUM_PUBLIC_ARTIFACT_ROOT from environment variables on every request, and docs/examples/apache_vhost.conf already sets these per-vhost via SetEnv. Two vhosts pointing at two deployed copies of the same code, each with its own three env vars, get fully separate content and databases today with zero application changes.

One important correction to "same repo": it should mean same source, not one literal public/ directory answering both hostnames. Static HTML artifacts are written as siblings inside public/, keyed by thread/post ID (public/threads/root-001.html); if zenmemes.com and chouse.club shared one public/ tree, their artifacts would collide on matching IDs. So: one repo, one release/build process, but two deployed instances (two public/ directories, two vhosts) — same pattern as deploying the same Docker image twice with different config, not literally the same running process serving two Host headers.

What isn't parameterized yet and needs to be: branding. Today SiteConfig::SITE_NAME is a hardcoded PHP constant, and there's no per-site default theme or composer copy. Extend the existing env-var precedence pattern (env override → site content flag → code default, already documented in production_deploy.md) one level further with a small site-profile registry, following the same shape as ThemeRegistry.php:

php
// src/ForumRewrite/SiteProfileRegistry.php (new)
final class SiteProfileRegistry
{
    public static function all(): array
    {
        return [
            'zenmemes' => ['name' => 'zenmemes', 'defaultTheme' => 'auto', /* existing copy */],
            'chouse'   => ['name' => 'chouse', 'defaultTheme' => 'chouse', 'composer' => [...]],
        ];
    }

    public static function active(): array
    {
        $id = getenv('FORUM_SITE_ID') ?: 'zenmemes';
        return self::all()[$id] ?? self::all()['zenmemes'];
    }
}

SiteConfig::SITE_NAME becomes SiteProfileRegistry::active()['name']; FORUM_SITE_ID gets set per-vhost next to the three existing SetEnv lines. This is a small, self-contained change and reuses an idiom (registry-of-profiles) already established by ThemeRegistry, rather than inventing a new configuration mechanism.

Key design decisions to make before building

These are real mismatches between chouse.club's current model and this framework's, not implementation details — flag them to the site owner before writing code.

  1. Private contact field. Canonical posts are public git-committed plaintext; there's no concept of "submitted but not shown." Options: (a) store contact info outside the canonical repo entirely — e.g. a private SQLite table or state/private/ file, written by the same compose request but never rendered or committed to records/; or (b) make contact info opt-in-public and drop the privacy guarantee. (a) preserves current behavior and is the recommended path — it's a small, isolated addition (one extra write next to the canonical post write), not a framework change.

  2. Structured submission fields vs. free-text body. The current form has three fields (what you're building / what help you need / contact). MVP: fold the first two into the post body as light structure (e.g. two labeled paragraphs), keep parity with thread_compose_form.php as-is. Later: add real help_needed as a second body field if the product wants it queryable/filterable — bigger effort, not needed for parity.

  3. Anti-spam posture. Recommend keeping anonymous submission (matches current openness) but enabling the approval/vouch flow and Dedalus analysis from day one rather than bolting it on after the spam shows up again, since that's the whole reason to migrate off the current setup.

  4. HTTPS. The production runbook's "don't force HTTPS, don't set HSTS" default is written for the general forum-identity case (public-HTTP OpenPGP fallback). A public site collecting contact info should run HTTPS (Let's Encrypt) as the primary path; keep the runbook's guidance about not force-redirecting or setting HSTS so a cert hiccup can't lock out the domain.

  5. ~~Migrating existing content.~~ Resolved: no migration — chouse's instance launches with an empty repository/database. See "Resolved" below.

Plan

Slice 1 — Site identity (site-profile registry)

  • Add SiteProfileRegistry (see architecture section above) with zenmemes and chouse profiles; resolve the active one from FORUM_SITE_ID at request start, default zenmemes for back-compat if the env var is absent (existing single-site deploys keep working unchanged).

  • Replace SiteConfig::SITE_NAME and the handful of places that hardcode it (FrontController.php:265,278,281, templates/pages/about.php) with reads from the active profile. Internal-only storage keys (zenmemes-theme localStorage key, etc.) can stay as-is — renaming them is cosmetic risk for zero user-facing value, and they're per-site anyway since each deployed instance has its own origin/localStorage.

  • Write a chouse-specific about.php variant (or a per-profile about body) alongside the existing zenmemes one.

  • Single-board mode for chouse: hide/collapse the tags and multi-board chrome on board.php when the active profile is chouse, since it's one flat feed, not a tagged multi-board forum (tags can still exist under the hood for later taxonomy use). zenmemes' board is unaffected.

Slice 2 — Composer parity

  • Repoint the home route at the board composer, relabel it: prompt "What are you building?", body placeholder split into "what you're building" / "what help you need," submit label "Submit."

  • Add the private-contact-field write path (decision #1 above): new optional form field, written to a non-canonical private store next to (not inside) the canonical post commit.

  • Feed heading → "Recent submissions."

Slice 3 — New "chouse" theme

Follow docs/runbooks/theme_development_guide.md exactly:

  • ThemeRegistry.php: add ['name' => 'chouse', 'label' => 'Chouse', 'mode' => 'light'].

  • public/assets/site.css: variable block, swatch, menu-row garnish, scoped section — same three-block pattern as every existing theme.

  • Design direction: minimal, text-forward, one strong accent color (not a literal Red Bull palette/logo copy — build an original mark inspired by the brief, since reusing another brand's trademark colors/logo verbatim is a legal risk for the site owner, not just a style choice). The vertical "CHOUSE" wordmark is a good CSS-only signature element — writing-mode: vertical-rl or a rotated fixed-position label, no image asset, matching the repo's no-asset theme convention.

  • Update tests/LocalAppSmokeTest.php allow-list per the guide.

  • Work in slices with a screenshot-driven verification pass (headed Chrome, ~380px viewport, theme popover leak check) as the guide prescribes — this is its own sub-plan doc when it starts.

Slice 4 — Moderation wiring

  • Enable/seed the approval-vouching flow so a first trusted identity exists at launch.

  • Wire Dedalus post analysis for submission quality/spam signal (reuses existing reply-agent style infra — no new provider integration).

  • Decide surfacing: hide flagged-spam submissions from the default feed view rather than deleting (keeps the git history honest).

Slice 5 — Deploy (two instances, one codebase)

Follow docs/runbooks/production_deploy.md / apache_vhost.conf, doubled:

  • One source checkout/release process, deployed to two independent instance directories:

    • /srv/zenmemes/app + /srv/zenmemes/repository + /srv/zenmemes/state

    • /srv/chouse/app + /srv/chouse/repository + /srv/chouse/state

    Each app/ gets its own public/ so static artifacts never collide (see architecture section — this is the one place "same repo" does not mean "same directory").

  • Two vhosts: ServerName zenmemes.com / ServerName chouse.club, each setting its own FORUM_REPOSITORY_ROOT, FORUM_DATABASE_PATH, FORUM_PUBLIC_ARTIFACT_ROOT, plus the new FORUM_SITE_ID (zenmemes / chouse) from slice 1.

  • Point chouse.club's DNS at the host; issue a Let's Encrypt cert (see decision #4 below) for chouse.club specifically — leave zenmemes.com's existing TLS posture alone unless asked to change it. Do not add forced HTTP→HTTPS redirect or HSTS on either vhost.

  • Initial read-model rebuild + static artifact build for chouse's instance only (zenmemes' is presumably already running); cron for run_agent_reply_requests.php per instance if Dedalus fulfillment is async, pointed at that instance's own paths.

  • Shared code changes (bug fixes, new themes, framework features) get released to both instances together; site-specific config (FORUM_SITE_ID and friends) stays per-vhost so one release doesn't need site-specific branches.

  • Walk the runbook's pre-launch checklist and manual-verification list for the chouse instance before pointing DNS; re-run it against the zenmemes instance too once slice 1's SiteProfileRegistry change lands there, since that's a shared-code change touching a currently-running site.

Open questions for the site owner

  • Keep contact info private (recommended, needs slice 2's private-store work) or accept it becoming public going forward?

  • Is Dedalus (or another LLM provider) already available/budgeted for spam analysis, or should slice 4 ship without it initially and rely on approval-gating alone?

Resolved

  • Content migration: not needed. chouse's instance launches with an empty repository/database — no import script, no hand-picking genuine submissions out of the current spam-heavy feed. Removes what was Slice 6 entirely.