01 — Philosophy

The architectural constraints that cascade through every other decision in BKA. Each one is load-bearing — break it and the thesis collapses into "yet another social platform."

1. No central content hosting, ever

The single most important constraint. The moment we host content for creators, we are the platform — we get to choose what loads, what's monetized, what's banned. The constraint:

When in doubt, ask: "do we have a copy of what the user sees?" If the answer trends toward yes, we're drifting toward platform.

2. The creator owns the infrastructure, not us

Each creator brings:

We provide the app (BKA), the templates (repo scaffold, viewer site), and the automation (publish pipeline config). We do not provide the substrate.

The corollary: creators can leave us at any time. Their content stays where it is. Their site stays where it is. Their audience never had to know we existed. Leavability is the test for sovereignty.

3. Friction lives at setup; runtime is frictionless

The Cloudflare-account step is real friction. We make it as smooth as possible (guided wizard, OAuth where available, copy-pastable commands) but we don't hide it. It's the price of sovereignty.

Once setup is done, everything else is one click or less:

This is the discipline: setup once, friction-free forever. If a workflow requires repeated manual steps post-setup, that's a bug.

4. Two repos per creator: private working DB + public published surface

The lifecycle is honest. Creators have drafts, scratch, full history, things they regret writing — those belong in a private repo nobody sees. The published artifacts they're proud of belong in a public repo that's their archive.

The publish action graduates content from private → public. The reverse (unpublish) deletes from public but keeps in private. Private is the source of truth for the creator's work; public is the curated outward face.

This also keeps the public repo small + fast + browsable on github.com. See 05_TWO_REPO_MODEL.md for specifics.

5. Federation over centralization

Even where we DO need a small central piece (the discovery indexer), it's pull-based: it visits creators' published feeds on a cadence, never receives pushes. This means:

The indexer is the smallest possible central thing. If it could be smaller still (zero), we'd make it zero. The minimum non-zero thing it does: serve discovery queries against the index it built from public feeds. See 07_DISCOVERY_LAYER.md.

6. AI at build time, AI in the discovery layer — never in the creator's request path

When a visitor hits a creator's site, no AI runs. No model call on page load. No personalization layer. The page is static-generated, served from edge cache, deterministic.

Where AI lives:

Both are bounded. Neither inflicts model unpredictability on the creator's own site experience. This mirrors the QC-harness / no-agents-as-product stance from the broader memory.

7. Same identity across the binary-blender app stack

Google SSO is the cross-app identity layer (per the community-pattern proof). When you sign into BKA, the same JWT works in Foundry, Community, and any future app. We never invent app-specific accounts.

For BKA specifically: the Google identity is used for the indexer's "this is my feed, please index it" registration call, and for any creator-to-creator or visitor-to-creator interactions that need attribution.

The creator's audience (their subscribers, commenters) don't need Google. They can subscribe via email (Cloudflare-side handler) or RSS (no identity at all). Identity is only required where the indexer or the cross-app surface needs it.

8. Automation is the product

The thing that justifies BKA's existence over "just learn Astro yourself" is that we automate the wiring nobody wants to do twice:

Every piece of automation is a one-time investment that frees the creator to actually create. If we ever find ourselves shipping a "now do this manually" instruction post-setup, that's a regression.

9. Open-source, no premium tier

The whole app ships under a permissive license (likely MIT). No paid tier. No feature flags gated behind subscriptions. The minute we add a "pro" tier we have a customer relationship and an incentive to lock creators in.

We sustain via:

The creator pays Cloudflare directly. We never see a dollar.

10. What this stack is NOT for