# 07 — Integration Playbook: Running (and Modding) the Stack

How TresPies/DojoGenesis actually operates on the Soapbox stack — four runbooks, one integration matrix, the build opportunities, and the TresPies modded-stack blueprint (steering direction, 2026-07-09).

**Verified: 2026-07-09.** Synthesized in the main thread from chapters 01–06 and 08–09 (each chapter carries its own numbered primary sources; this chapter cites chapters). Facts cross-checked across chapters; two contradictions found and resolved during assembly (Armada existence — ch. 02 corrected; Blossom Drive deprecation — ch. 02 aligned to ch. 06).

## 0. The operating rule that governs everything: the AGPL boundary

```mermaid
flowchart TB
    subgraph open [OPEN LAYER - published, AGPL obligations accepted]
        F[Forks of apps: Ditto / Armada / Agora / Shakespeare]
        M[i18n + viz mods - contribute upstream where possible]
    end
    subgraph safe [PERMISSIVE LAYER - closed OK]
        FW[Nostrify MIT confirmed · MKStack template: NO license file, ch. 10 · your own apps built on them]
    end
    subgraph private [PRIVATE LAYER - never in the fork]
        P[Client-specific work · IP-sensitive logic · data, content, config, themes-as-config, keys]
    end
    F --> M
    FW --> P
    M -. "client deployments compose open base + private layer" .-> P
```

Soapbox apps are AGPL-3.0: a modded, client-facing deployment must publish its modifications (ch. 01). The rule: **i18n/viz mods live in the open layer** (good citizenship in a grant-funded ecosystem, and it's the build-in-public playbook anyway); **client work and IP live in config/content/plugin layers on top, never in the fork**; anything that must stay closed gets built on Nostrify (MIT, confirmed). Ch. 10 nuance: the MKStack *template* ships no license file at all — likely an oversight and boilerplate norms suggest reuse is expected, but get explicit terms from Soapbox before a closed commercial fork — and mkstack-nsp (the AI backend) is AGPLv3, so a self-hosted modified NSP owes its source to its users. **Ratified 2026-07-09** — ADR: `0001-mod-layer-rule` (the maintainers' companion decision record; not shipped with this public chapter set; internal: PIP-94 phase 1 closed); residual item: ask Soapbox for explicit MKStack-template terms before any closed commercial fork.

## 1. Decision summary

| Need | Use | Not (yet) | Chapter |
|---|---|---|---|
| Public branded community | Ditto (self-host or ditto.pub while piloting) | Armada (too young for public-facing) | 02 |
| Internal team chat, E2E | Armada pilot (low-stakes channels first) | Betting company ops on 0.x | 02 |
| Team file storage (binary/office assets) | Keep Drive/Dropbox | Blossom as a drive (no folders/ACLs/versions) | 02, 06 |
| Team knowledge (md + git + memory autosync) | Git-anchored via NIP-34/GRASP (§9.3.6) | Needing Drive for md-native work | 05, §9.3 |
| Fundraising rail (BTC-native, censorship-resistant) | Agora | Replacing GoFundMe for normie donors (no card checkout) | 03 |
| Client mockups at volume | Shakespeare, free tier / cheap BYOK | — | 04 |
| Production client sites + funnels | Shakespeare + external conversion stack | Client self-editing (no CMS) | 04 |
| Developer distribution / credibility | NostrHub 2.0 (repos, apps, articles) | Expecting it to be a growth channel | 05 |
| Bilingual layer | Fork Agora's i18next pattern + Lingo.dev | Waiting for a Nostr language NIP (none ratified) | 08 |
| Equity-data dashboards | MapLibre+PMTiles+ECharts, zero-server | Viz inside Ditto (no widget surface) or 30023 (no HTML) | 09 |

## 2. Day 1 with your credentials (do this before anything else)

Ch. 06 §1 has the full version with sources; the sequence:

1. **Back up the nsec offline** — password-encrypt it as `ncryptsec` (NIP-49). There is no reset and no ratified key rotation; losing it is identity loss.
2. Install a **NIP-07 signer extension** (Alby or nos2x) on your main machine. The key never touches websites.
3. Stand up a **NIP-46 bunker** (nsec.app; Amber on Android) the moment a second device or teammate is involved.
4. Publish your **kind-0 profile** (name, bio, avatar) from a real client.
5. Claim **NIP-05**: `you@yourdomain.com` = one static JSON at `https://yourdomain.com/.well-known/nostr.json` (no redirects allowed). Minutes on existing infra.
6. Pick relays deliberately — **2–4 write relays + a few read** (NIP-65 outbox), not twenty.
7. Log into **NostrHub with the extension** (never the nsec-paste or key-file options it also offers — ch. 05).
8. First publishes: a kind-1 note; then a kind-30023 long-form to test the publishing path.
9. Decide the **org-account pattern**: brand account (shared via bunker) + personal accounts; document custody (who holds what, where the ncryptsec backups live).
10. Wallet: connect via **NWC (NIP-47)** for zaps; treat received sats as accounting events from day 1 (ch. 06 §4 flags the tax reality).

## 3. Runbook A — Community and company ops

**Shape:** Ditto = the storefront community (public, branded, bridged); Armada = the back office pilot (E2E, internal). They are different products, not versions of one thing (ch. 02).

| Step | Ditto (public) | Armada (internal pilot) |
|---|---|---|
| 1. Stand up | Join flagship `ditto.pub` to learn the UX, then self-host: Deno + Postgres + Nginx/Certbot (real ops, not a $5 static VPS — ch. 02) | Open the web app from soapbox.pub/armada; Zapstore for Android; Electron for desktop |
| 2. Brand | Custom domain, themes (9 presets / 19 CSS tokens; beyond that = fork → AGPL layer) | Create server → channels/threads/roles |
| 3. Team | Staff accounts via bunker; moderation = Mastodon-style admin tools | Invite via Concord invites (gift-wrapped over public relays; no server to run) |
| 4. Reach | Mastodon-API apps (50+ clients), Mostr bridge → Fediverse, → Bluesky (~15 min lag) | Keep to low-stakes channels until audited; export nothing sensitive yet |
| 5. Media | Blossom uploads (100 MiB cap; 20 MiB on free servers), plaintext URLs | E2E-encrypted images/media in-channel |

**Filesharing verdict stands:** neither is a Drive replacement (no folders/ACLs/versioning; the one folder app, Blossom Drive, is deprecated — Bouquet manages blobs only). Keep Drive; use the stack for community media and E2E chat attachments.

**Watch item:** Ditto has no native DMs today (NIP-17 absent) and implements neither NIP-72 nor NIP-29 groups (roadmap). For private conversation, Armada is the answer; don't promise DM privacy on Ditto.

## 4. Runbook B — Funding on Agora

**When Agora:** BTC-native donor base, censorship-resistance matters, zero platform fees matter, or client is an activist/civic org comfortable with crypto. **When not:** normie donors (no card checkout), US 501(c)(3) needing tax receipts (anonymous Silent-Payment gifts can't get IRS-compliant receipts — ch. 03), or discovery-dependent campaigns.

1. Campaign creation is **permissionless** — any Nostr keypair; "featured" is curated (WLC/HRF human-rights positioning).
2. Donations flow **wallet-to-wallet on-chain BTC** (incl. BIP-352 Silent Payments). Agora never holds funds; $0 platform fee; donor pays network fee.
3. Lightning zaps exist in Agora only as **social tipping**, a separate rail from campaign donations — don't conflate them in client explanations.
4. Publish campaign updates on Nostr; donations are publicly auditable (blockchain + Nostr) — a transparency feature for community orgs.
5. Off-ramp is manual: raised BTC → exchange (KYC reappears there) → USD; plan the volatility window.
6. **Embedding: none.** Shakespeare sites link out to the campaign; no widget exists (ch. 03). Zap-goal (NIP-75) integration unconfirmed.
7. White-label: AGPL fork-and-run is feasible (static React/Vite, Docker) for a client's own campaign platform — publishes your mods per §0.

## 5. Runbook C — Sites, funnels, mockups on Shakespeare

**Mockup economics (the agency loop):**

| Lane | Cost | Use for |
|---|---|---|
| Free Gemini Flash tier (promotional — verify live before quoting) | $0 | Volume first-pass mockups |
| BYO API key, cheap model (e.g. GLM-class) | Cents per mockup; Soapbox takes no cut | Iteration rounds |
| Local models (Ollama) | $0 after hardware | Offline/batch |
| Paid NSP (MKStack + Claude Sonnet) | Paid via Stripe/Lightning | The deal that's closing |

**Funnel wiring — what's native vs external:**

```mermaid
flowchart LR
    V[Visitor] --> S[Shakespeare site - static React on MKStack]
    S -->|native, one prompt| F[Contact form]
    F -->|wire explicitly| BH[Beehiiv / ManyChat]
    S -->|embed| CAL[Cal.com scheduling]
    S -->|native| LN[Lightning / Cashu payments - NIP-57/60/61/47]
    S -->|manual wire| ST[Stripe for card clients]
    S -->|link out| AG[Agora campaign]
    S -->|join CTA| D[Ditto community - retention layer]
```

The trap: forms **render** with one prompt but there is no backend — where submissions land must be explicitly wired to an external service or they land nowhere (ch. 04). Payments are the inverse: Lightning/Cashu is genuinely native (Agora proves it in production); Stripe is the manual add.

**Deploy paths:** free `*.shakespeare.wtf` for mockups → export ZIP/git (including `nostr://` git URLs) → production on Netlify/Vercel/Cloudflare/Pages, or fully decentralized via nsite + Blossom (Stacks CLI). Custom domains observed live but no documented runbook — budget discovery time. **Client caveat:** no CMS/visual editor; whoever builds it owns the edits (a retainer surface — position it as such to a client).

## 6. Runbook D — Publishing on NostrHub 2.0

1. Log in via NIP-07 extension (§2).
2. **Repo:** create/mirror → signs a kind-30617 announcement → lives on a GRASP host (relay+git) → issues/PRs/browsing on NostrHub; the same repo is clonable via gitworkshop.dev/ngit (interop verified live — ch. 05).
3. **App:** self-announce a kind-31990 NIP-89 handler event — no submission queue; community ratings accrue.
4. **Article/docs:** kind-30023 markdown; your chosen experts' NIP-32 approvals drive per-viewer ranking ("configurable meritocracy").
5. Expectations: it is a **credibility and discovery layer, not a growth channel** — metadata only (no artifact hosting), no auto-propagation to Zapstore/nostrapps (list those separately).

## 7. Integration matrix

| From | To | Mechanism | Enables | Status |
|---|---|---|---|---|
| Any product | Identity | Nostr keypair + NIP-07/46 signer | One login everywhere | Live |
| Ditto | 50+ Mastodon apps | Mastodon API + bunker login | Mobile clients day 1 | Live |
| Ditto | Fediverse / Bluesky | Mostr bridge (+Bridgy Fed) | Cross-network reach | Live (lag) |
| Ditto/Armada | Blossom servers | BUD specs | Swappable, mirrorable media | Live |
| Armada | Public relays | Concord gift-wrap (NIP-59) | Serverless E2E ops | Early (0.x) |
| Shakespeare | MKStack | Generation target | Nostr-native apps incl. Recharts, zaps | Live |
| Shakespeare site | Agora | Link-out only | Campaign traffic | Live (no embed) |
| Shakespeare site | Beehiiv/ManyChat/Cal.com/Stripe | Prompted API wiring | Real conversion funnel | Manual |
| Shakespeare/repos | NostrHub | kind 30617 / 31990 / 30023 | Publishing + discovery | Live |
| NostrHub repo | gitworkshop/ngit | NIP-34 + GRASP | Clone/PR from any NIP-34 client | Verified |
| Any app | Wallets | NIP-57 zaps, NIP-47 NWC, Cashu 60/61 | Payments without processors | Live |
| Agent orchestrators | Nostr jobs | DVM pattern (kind registry; base NIP-90 deprecated) | Paid agent job market | Scout |

## 8. Build opportunities

1. **DVM-shaped agent dispatch** — the data-vending-machine pattern (post job → providers compete → paid in sats) is structurally identical to an internal agent-dispatch queue like `dojo_agent_dispatch` (ch. 06, worked example) — the maintainers use this shape today. A thin bridge would put any agent orchestrator on an open job market. Scout, not dependency.
2. **Ditto bots via Mastodon API** — the entire Mastodon bot/tooling ecosystem works against a Ditto instance; cheapest automation surface in the stack.
3. **MCP ↔ Nostr bridge** — publish/read Nostr events as MCP tools (post, zap, fetch community signals); nothing found in the ecosystem occupying this niche.
4. **The bilingual mod layer itself** (§9.2) — first-mover OSS contribution with obvious upstream demand: Soapbox's own builder UI has no Spanish (ch. 08).
5. **Concord early expertise** — protocol is 26 days old (CORD-01–07); early implementers get standing in whatever it becomes.

## 9. The TresPies modded-stack blueprint (steering direction, 2026-07-09)

What follows is the maintainers' own integration plan, published as a worked example of wiring this stack into a real firm — adapt the shape, swap the specifics (a different niche, a different orchestrator, a different git-mirror target) for your own.

Operator direction, verbatim: *"integrate this stack with cutting edge internationalization platforms and visualization platform components then we'll build a Tres Pies stack on the modded version and git anchor it all in Nostr, mirror it to Dojo Genesis Git."* (internal: PIP-94). Phase gates below assume §0's mod-layer rule is ratified first.

### 9.0 AI + orchestration layer (operator-specified 2026-07-09)

Direction, verbatim: *"built featuring my dojo orchestration system and the providers of your choice: enterprise or TresPies or windsurf or cursor or whatever or Local: OpenRouter or Dojo Genesis."*

The build engine is **Dojo orchestration** (Gateway agent-dispatch + Claude Code sessions) driving generation against **MKStack's AGENTS.md agent contract** — 348 lines at the template root, shipping with `.mcp.json` (Claude Code's own MCP config), `opencode.json`, and 19 skill files (ch. 10; note `NIP.md` is a different artifact — the NSP wire protocol in mkstack-nsp). Shakespeare becomes one optional front-end among several, not the required lane. All lanes target the same scaffold:

| Lane | Driven by | Models from | When |
|---|---|---|---|
| Enterprise | Claude Code / direct API | Anthropic enterprise (or the client's own) | Client work with contract/compliance requirements |
| TresPies-hosted | Dojo Gateway dispatch | TresPies keys | House builds, POCs, batch generation |
| IDE agents | Windsurf / Cursor / "whatever" | Their provider config | Operator-in-the-loop editing sessions |
| Local / routed | Any agent | OpenRouter or DojoGenesis Gateway (incl. local models) | Cost-floor mockup volume, offline work |

**Rule: no lane lock-in.** The scaffold + AGENTS.md contract must build identically from every lane — the zero-lock-in founder veto applied to our own tooling. Ch. 10 confirms it: a raw clone is Claude Code-ready out of the box (AGENTS.md + `.mcp.json` + skills), local lanes impose no model provider, and only hosted Shakespeare and Stacks/Dork touch a Soapbox-rostered model list. The one unbuilt extension point: a Dojo-Gateway `AI_PROVIDER` adapter for a self-hosted mkstack-nsp (only OpenAI/OpenRouter adapters exist today — and a self-hosted NSP is AGPLv3, so modified server source must be published).

### 9.1 i18n integration (from ch. 08)

- **Runtime:** keep i18next/react-i18next — already proven *inside this stack* by Agora (16 locales, es at 99.96% parity). Fork Agora's `src/i18n.ts` pattern into the Ditto/Armada-derived base rather than importing a foreign architecture.
- **Automation:** layer **Lingo.dev** (Apache-2.0, CI-native AI-MT with glossary/brand-voice control) for machine passes; TresPies native-Spanish review stays the human gate.
- **Gate:** port the NS-style **symmetric parity check** into CI — Agora's existing gate fails only on extra keys, not missing ones; tighten it.
- **Nostr layer:** no ratified language NIP (Gleason's own NIP-37 closed unmerged; PR #1127 open) — adopt the de facto NIP-32 labels `["L","ISO-639-1"] ["l","es","ISO-639-1"]` for bilingual content now.
- **Contribution play:** Ditto and Armada have literally zero i18n today; Shakespeare's UI has no Spanish. A clean es layer is a visible, welcomed upstream contribution (and marketing).

### 9.2 Visualization integration (from ch. 09)

- **Spec-layer rule:** framework-agnostic engines (ECharts, MapLibre GL) bridge the React stack and Svelte house surfaces; framework-bound charts route per surface (Recharts inside Shakespeare/MKStack — it ships in the scaffold; LayerChart/unovis in Svelte dashboards).
- **The Atlas pattern (zero-server):** ACS/TIGER → Tippecanoe → **PMTiles + Parquet** on static hosting → MapLibre choropleths + DuckDB-WASM drill-down → bilingual labels via §9.1 hooks. No origin server anywhere; deployable to Pages/R2 or nsite/Blossom.
- **Tripwire:** PMTiles needs HTTP range requests; Blossom's spec only *recommends* them — verify per Blossom server or default to Cloudflare R2 (documented Protomaps path).
- **Position:** no Nostr+census precedent found — an Atlas on this substrate is first-of-kind for the maintainers' §1557/equity-data niche (swap in your own domain — the zero-server pattern doesn't care what the data is).

### 9.3 Git-anchor + mirror runbook

1. Repo canonical home: GRASP host (relay + git server) with a **kind-30617 announcement** signed by the TresPies/DojoGenesis key (per repo).
2. Add the GitHub mirror: `git remote add github git@github.com:DojoGenesis/<repo>.git` — **`gh auth switch --user DojoGenesis` first** (existing guard, enforced by hook).
3. Push discipline: anchor push (ngit/GRASP) then mirror push; CI or a post-push hook keeps them in lockstep. `nostr://` remotes are already supported by Shakespeare's git export (ch. 04).
4. Issues/PRs: NIP-34 events — workable from NostrHub or gitworkshop.dev interchangeably (verified interop, ch. 05).
5. **What stays off the anchor:** anything under IP gate or client NDA — Nostr announcements are public and permanent; private repos stay GitHub-only until the maintainers are ready to publish them (their standing practice for moving in-progress internal work into the open).
6. **The knowledge layer rides this rail (operator call, 2026-07-09):** because the operating model keeps knowledge as markdown in git (manuals, notes, ADRs, the memory system with local autosync), git-over-Nostr IS the internal file layer for knowledge work — anchored, mirrored, versioned. This narrows §1's "keep Drive" verdict to binary/office assets only (client spreadsheets, design files, video); md-native ops need no Drive.

### 9.4 Sequencing (30/60/90) and tripwires

| Window | Moves | Gate |
|---|---|---|
| 0–30d | Day-1 credentials (§2) · NIP-05 on your domain · Shakespeare mockup lane in client workflow · Armada internal pilot (low-stakes) · ratify mod-layer rule | Phase 1 (operator; internal: PIP-94) |
| 30–60d | i18n fork: Agora pattern → Ditto base + Lingo.dev CI + symmetric gate · first repo git-anchored + DojoGenesis-mirrored · NostrHub presence (repo + article) | Parity gate green |
| 60–90d | Atlas-pattern reference dashboard (PMTiles static) · Ditto community soft launch (bridged) · evaluate Agora campaign for a real client cause · upstream the es layer | First-of-kind demo live |

**Tripwires:** Armada security audit status (none yet — recheck before widening pilot) · Shakespeare free-tier lapse (promotional, no end date) · Soapbox grant renewals (their existential risk, ch. 01) · Blossom range-request support (per-server) · Concord protocol churn (already v1→v2 in 26 days).

## 10. Consolidated open questions

Highest-value unknowns across chapters (each chapter lists its own in full): Armada arbitrary-file attachments and audit roadmap (02) · Agora NIP-75 zap-goal use and Forbes/AP coverage verification (03) · Shakespeare custom-domain runbook and free-tier durability (04) · NostrHub DVM-marketplace status in 2.0 and license file (05) · Agora zap-vs-donation edge mechanics (03/06) · whether Soapbox would accept an es upstream contribution PR promptly (08 — ask them directly; they're reachable on their own products).