← Back to Whitepapers

ForgeBio

The sovereign Beacons-killer — a vault-driven, NOAH-embedded, chain-anchored link-in-bio page with zero vendor rent

NODEZEROINSIDE.

0. Abstract

ForgeBio is the ForgeChainOS replacement for Beacons.ai / Linktree / Stan Store / Bento / Linkpop: a per-tenant "link-in-bio" page that is not a vendor's rented row of links but a sovereign surface rendered directly from the tenant's own Obsidian vault. One function, render_bio(slug), reads the tenant's vault state — a links.md config, the latest published blog post, the sovereign-person identity seal, avatar and cover images — and emits a single self-contained mobile-first HTML page. The design payload beyond a plain link list is fourfold: (1) a sovereign-person seal badge that lets a visitor verify, via a chain TX on WhatsOnChain, that they are dealing with the real client; (2) a NOAH visitor-chat embed so a visitor can talk to the client's assistant on the page itself; (3) vault-driven live blocks (latest blog renders live, not a static screenshot); (4) hybrid BSV + Stripe commerce with chain-anchored receipts for collector provenance — at zero per-transaction rent (Beacons takes 9% on free tiers). The audience hits the CLIENT's domain, not a vendor's.

Reality line (grounded 2026-07-05): the renderer is BUILT and proven by running — it produces valid HTML from a real vault. The economic and identity architecture around it is DESIGN/VISION: the NOAH chat widget, the sovereign seal in production, the BSV+Stripe checkout, live inventory / shows / email-capture blocks, and the served public URL are not yet built. This paper marks the line explicitly so no session builds on a ghost (scar #5 discipline). Build-step 1 of a 10-step queue is shipped; steps 2–10 are canon-locked and pending.

Definition (NZ canon): ForgeBio = a sovereign link-in-bio page. NZ canon-stamp: "Forge Bio sovereign — build it" and "IS beacons the right choice? can we simulate or do better than beacons?" The answer this module encodes: do better, on our own metal, with no rent and no impersonation surface.

1. Why ForgeBio exists

A Beacons/Linktree page is a rented room. The vendor owns the URL, owns the audience data, takes a cut of every sale (Beacons: 9% on free, 2–3% on paid), and offers no way for a visitor to prove the account is genuinely the artist and not an impersonator. For an Eclipse Film Crew client — Kate Hoekstra selling paintings, Tommy O'Connor selling merch and show subscriptions — the vendor sits between the artist and the collector on both the money and the trust.

ForgeBio inverts it. The page is generated from the tenant's own vault and served from the tenant's own domain; the money moves directly to the client's wallet or Stripe-Connect account (Eclipse Film Crew never custodies client revenue); and the visitor can verify the artist's identity against the chain.

Beacons / Linktree ForgeBio
Vendor URL (beacons.ai/kate) Client's own domain — <client-domain>/links (sovereign URL)
9% on free / 2–3% on paid Zero per-transaction rent on BSV; Stripe pass-through only
Static blocks, manually edited Vault-driven live blocks — latest blog renders from blog/published/ at render time
No identity assurance Sovereign-person seal — ✓ Verified, links to the identity-seal TX on WhatsOnChain
No assistant NOAH visitor chat embedded — visitor talks to the client's tier_4_external persona (design)
No provenance Chain-anchored receipts — collector first-sale provenance (design)
Vendor holds audience data Mailing list lives in the vault (audience/email-list.md), not Mailchimp

The renderer is the part that exists today. The economics and the trust layer are the payload it is being built to carry.

2. The one input surface (vault-driven)

ForgeBio authors no separate CMS. Its entire input is the tenant's vault — the SAME vault NOAH reads and the Forge Filmcrew loop writes. render_bio(slug) composes from these sources, each optional and each degrading gracefully to nothing if absent:

Because every block reads live vault state, an edit in Obsidian propagates to the bio page on the next render — the manifest's design intent is that an inventory or link edit propagates from vault → bio block → main site → socials simultaneously. That cross-surface propagation is the vision; the vault-read-at-render mechanism is built.

3. What the renderer emits (BUILT)

render_bio(slug) returns a single self-contained HTML document — inline CSS, inline SVG icons, images embedded as data-URIs, no external requests except the NOAH widget script tag. It is mobile-first (max-width: 460px, safe-area insets, tap-scale feedback). Sections, each conditional on data being present:

Output is written to sites/<slug>/dist/bio-live.html.

Proven by running (2026-07-05): render_bio("lilac-inn-art-gallery") and render_bio("eclipse-film-crew") both returned ok=True and wrote valid ~4.4 KB HTML documents. Because those vaults carry no links.md, no published post, and no sealed account yet, the run reported links_count=0, has_featured=False, has_seal_badge=False — the skeleton renders correctly and every content block degrades to empty rather than erroring. That is the honest state: the engine works; the tenant content and the surrounding rails are not yet authored/built.

4. Identity — the sovereign-person seal (the anti-impersonation surface)

The seal is the one thing Beacons structurally cannot offer. It comes from the forgeOnboarding WebAuthn SOP (webauthn_sop.py): a device-native biometric (Face ID / Touch ID / Hello) mints a WebAuthn passkey; the public key plus a deterministic IPv6 Rodin tile plus a "Sovereign Person — All Rights Reserved Under Natural Law" statement are hashed into an identity_seal and chain-anchored via a family-encrypted fire. ForgeBio reads that seal from the account JSON and renders the ✓ badge with a link to the TX.

A visitor clicking the badge lands on WhatsOnChain and sees the artist's identity attestation on the immutable ledger. That is the impersonation defense: not a blue check a platform grants and can revoke, but a chain fact the artist owns. Built: the seal reader and badge renderer. Vision/pending: an actual sealed accounts/<slug>.json for a live client — none present on disk yet, so the badge path is unexercised in production.

5. Commerce — Hybrid C3, zero rent (DESIGN)

The manifest specifies Hybrid C3: BSV-native checkout (HandCash redirect, RelayX deeplink, or a direct bitcoin:<address>?amount=… BIP-21 URI) plus a Stripe pass-through (per-tenant Stripe Connect account). The revenue model is a service fee per client contract, never a per-transaction cut: 0% on BSV, Stripe's own 2.9% pass-through on fiat. Funds flow directly to the client — Eclipse Film Crew never custodies. Order state lives in the vault (<slug>/orders/<iso>-<sku>.json, pending_payment → paid → fulfilled), and a per-piece chain anchor is available on client opt-in (default family-encrypted; public-intent only when the client explicitly opts that piece — e.g. Kate wanting a chain-attested first-sale date as collector provenance).

None of the checkout is built. The renderer today emits only the "visit main site" CTA. Steps 5 (BSV paths), 6 (Stripe Connect + Checkout), and 7 (order state machine + chain-anchor) are canon-locked, unbuilt. This section is the target, not a claim.

6. NOAH on the page (DESIGN)

The differentiator over a static link list is a live assistant. The design: a visitor opens the chat widget and talks to the client's tier_4_external NOAH persona about the work, prices, and availability; a buying signal routes the conversation to the client's inquiries with high priority; the same widget can be embedded on the client's main site via forge-bio-widget.js. The renderer already emits the widget <script> tag wired with data-slug and data-tier. The widget JavaScript itself (noah-widget.js) does not yet exist on disk — the embed points at a file to be built (build_queue step 2). NOAH's chat backend runs on BH; the front-end widget is the missing piece.

7. Where it sits — one loop with Forge Filmcrew

ForgeBio is not a standalone app. It is a renderer in the Forge Filmcrew suite (obs-stream-mcp/, alongside forge_filmcrew_content.py, _intake.py, _renderer.py, _scheduler.py), canonized as a composing surface within Forge Filmcrew's Sovereign Production Loop (doctrine 2026-06-08). It composes with forgeonboarding_webauthn_sop (the seal), tenant_obsidian_vault (the input), noah_router (the chat), phi_omega_v6_batch_fire (the anchor), and forgepath (the sovereign URL). The multi-tenant compound effect is the strategic point: one dev improvement to the renderer benefits every client at once, and the page is black-start resilient — vault-backed, servable from forge-edge OR BH OR a client mirror.

Nodes: BH (vault state + NOAH chat backend), Elder I (manifest + chain fires), forge-edge (the intended public surface + checkout SPA).

8. Status & sequencing — BUILT vs DESIGN, honestly marked

Manifest status is build_step_1_shipped_2026-06-08. Grounded against disk 2026-07-05:

Total remaining effort per manifest: ~21 hours, ~4 focused sessions. First client: Kate Hoekstra (paintings as 1-of-1 BSV ordinals OR Stripe-fiat). Second: Tommy (Killer Momentum merch + show subscriptions).

Correction to any "live at theforgechain.com/…" reading: the renderer writes a file; it is not wired to a served route. Treat the URL claims in the manifest as the intended surface, not a running one.

Home: ~/.forgechain/services/obs-stream-mcp/forge_bio_renderer.py (git 60f14e6). Doctrine: [[doctrine_forge-filmcrew-sovereign-production-loop-2026-06-08]]. Manifest: tools.forge_bio.

This paper is family-internal — NOT for public fire. It maps the module's structure and its honest build line (scar #5 surface: do not overstate to chain, do not stamp family-internal content public). If a public account of ForgeBio is ever wanted, author a public-safe vision paper separately — do not stamp this one.

NODEZEROINSIDE. ∞.