docs(consultation): Gemini consult — ModpackChecker Phase 11 full licensing spec
Complete implementation spec request covering: - Validation API design (endpoints, schema, security) - Phone-home cron (72hr check, 7-day grace, degradation) - Discord support verification bot - BuiltByBit listing strategy (pricing, updates, structure) - Build/package pipeline - Testing strategy This is the last gate before ModpackChecker goes to market. Claude (Chronicler #83 - The Compiler) <claude@firefrostgaming.com>
This commit is contained in:
Claude (Chronicler #83 - The Compiler)
parent
f31b3dba95
commit
2293f6a11c
@@ -0,0 +1,123 @@
|
||||
# Gemini Consultation: ModpackChecker Phase 11 — Complete Licensing & Distribution System
|
||||
|
||||
**Date:** April 12, 2026, ~1:30 PM CDT
|
||||
**From:** Michael (The Wizard) + Claude (Chronicler #83 — The Compiler)
|
||||
**To:** Gemini (Architectural Partner)
|
||||
**Re:** Full implementation spec for the licensing, validation, and distribution system before ModpackChecker goes to market on BuiltByBit
|
||||
|
||||
---
|
||||
|
||||
## Hey Gemini! 👋
|
||||
|
||||
We're following through on your Round 3 consultation (licensing/support strategy). The ModpackChecker Blueprint extension and Python CLI have both been code-reviewed and cleaned up (20 bugs fixed today, 71 Python tests passing). The code is ready — now we need to build the complete commercial packaging before we list on BuiltByBit.
|
||||
|
||||
Michael wants to ship a **complete package** — not a v1.0 without licensing that gets bolted on later. So we need the full Phase 11 implementation spec.
|
||||
|
||||
---
|
||||
|
||||
## What Already Exists (Your Prior Decisions)
|
||||
|
||||
From your Round 3 consultation, the decisions were:
|
||||
|
||||
1. **License key = BuiltByBit Order ID** — no key generation
|
||||
2. **Lightweight validation API** on our server, phone-home every 72 hours via cron
|
||||
3. **7-day grace period** if validation fails → graceful degradation
|
||||
4. **2 activations per license** (dev + production)
|
||||
5. **Anti-piracy:** No DRM/IonCube. Gated updates + gated support is the real moat
|
||||
6. **Discord support gating:** `/verify-mvc [order-id]` → bot assigns role → unlocks support channels
|
||||
7. **SLA:** 24-48 business hours, Mon-Fri 9-5 CST
|
||||
|
||||
---
|
||||
|
||||
## What We Need You to Spec Out
|
||||
|
||||
### A. Validation API (runs on Command Center — 63.143.34.217)
|
||||
|
||||
We need the full API design:
|
||||
|
||||
1. **What technology?** Standalone Express app? New routes in Arbiter? Cloudflare Worker? What makes the most sense given our existing stack (Arbiter is Node.js/Express on Command Center)?
|
||||
|
||||
2. **Database schema** — What tables do we need? At minimum:
|
||||
- Licenses (order_id, customer_email, product, max_activations, created_at)
|
||||
- Activations (license_id, panel_domain, panel_ip, activated_at, last_seen)
|
||||
- What else?
|
||||
|
||||
3. **API endpoints** — What does the extension call, and what does it get back?
|
||||
- `POST /api/license/activate` — first-time activation (sends order_id + panel domain)
|
||||
- `POST /api/license/validate` — the 72-hour phone-home (sends order_id + panel domain)
|
||||
- `POST /api/license/deactivate` — frees up an activation slot
|
||||
- Anything else?
|
||||
|
||||
4. **Response format** — What does each endpoint return? What does "graceful degradation" look like in practice? Does the extension hide features? Show a banner? Stop checking for updates?
|
||||
|
||||
5. **Security** — How do we prevent someone from spoofing the validation? HMAC signing? The order_id is essentially a shared secret — is that sufficient, or do we need something more?
|
||||
|
||||
6. **BuiltByBit webhook integration** — BuiltByBit can send webhooks on purchase. Should we auto-provision licenses when someone buys, or require manual activation? What webhook events does BuiltByBit send?
|
||||
|
||||
### B. Phone-Home Cron (runs inside the Blueprint extension on customer's panel)
|
||||
|
||||
1. **Implementation** — Laravel Artisan command scheduled via `conf.yml`? How does Blueprint handle scheduled tasks?
|
||||
|
||||
2. **What gets sent** — Order ID, panel domain, panel IP, extension version, PHP version? What's the minimum needed without being creepy?
|
||||
|
||||
3. **Failure handling** — 72-hour check fails → extension keeps working for 7 days → then what exactly? Disable the dashboard badge? Disable the console widget? Show a "license expired" banner? All of the above?
|
||||
|
||||
4. **First-time activation flow** — Admin installs extension → goes to admin settings → enters BuiltByBit Order ID → extension calls activate endpoint → success/failure → what does the UI look like?
|
||||
|
||||
### C. Discord Support Verification Bot
|
||||
|
||||
1. **Implementation** — New Arbiter command? Standalone bot?
|
||||
|
||||
2. **Flow:** User types `/verify-mvc ORDER_ID` → bot checks validation API → if valid, assigns `ModpackChecker Customer` role → unlocks `#mvc-general` and `#mvc-support` channels
|
||||
|
||||
3. **Edge cases** — What if someone shares their order ID? Rate limiting? Can the same order ID verify multiple Discord accounts?
|
||||
|
||||
### D. BuiltByBit Listing
|
||||
|
||||
1. **Product page structure** — What sections does a successful BuiltByBit listing need? Title, description, feature list, requirements, installation guide, support terms, screenshots, pricing?
|
||||
|
||||
2. **Pricing** — What's the right price point for a Pterodactyl Blueprint extension in 2026? We've seen competitors at $5-$15. What should ModpackChecker be?
|
||||
|
||||
3. **Update distribution** — How do customers get updates? BuiltByBit download page? Our own update server? Both?
|
||||
|
||||
4. **Version numbering** — We're at 1.0.0 internally. Should we ship as 1.0.0 or something higher to imply maturity?
|
||||
|
||||
### E. Build & Package Pipeline
|
||||
|
||||
1. **Blueprint package** — `build.sh` already creates the `.blueprint` file. Does it need modification to include license validation code?
|
||||
|
||||
2. **Obfuscation** — You said no IonCube, but should we do any basic PHP obfuscation to raise the bar slightly? Or is it truly not worth the effort?
|
||||
|
||||
3. **Release checklist** — What's the step-by-step from "code is done" to "listed on BuiltByBit"? Every step.
|
||||
|
||||
### F. Testing Strategy
|
||||
|
||||
1. **How do we test the full license flow** on the Dev Panel before going live? Mock BuiltByBit orders? Test activation/deactivation/grace period?
|
||||
|
||||
2. **What could go wrong** in production that we should build monitoring for?
|
||||
|
||||
---
|
||||
|
||||
## Our Infrastructure Context
|
||||
|
||||
- **Command Center** (63.143.34.217): Arbiter (Node.js/Express), PostgreSQL, Gitea
|
||||
- **Dev Panel** (64.50.188.128): Pterodactyl + Blueprint beta-2026-01 (test environment)
|
||||
- **TX1 Dallas** (38.68.14.26): Game servers, n8n
|
||||
- **Discord bot:** Arbiter's existing bot (already has command infrastructure)
|
||||
- **Build tool:** Claude Code on Dev Panel via SSH
|
||||
- **Existing Arbiter DB:** PostgreSQL `arbiter_db` on Command Center
|
||||
|
||||
---
|
||||
|
||||
## Constraints
|
||||
|
||||
- Michael has hand surgery limitations — the admin UI for license entry must be dead simple
|
||||
- We want to minimize ongoing maintenance burden — this should mostly run itself
|
||||
- No external SaaS dependencies for licensing (we host everything)
|
||||
- Blueprint beta-2026-01 is our target platform — need to verify any scheduled task approach works with this version
|
||||
|
||||
---
|
||||
|
||||
Thanks Gemini! This is the last big piece before ModpackChecker starts generating revenue. We want a complete, professional, self-hosted licensing system that makes us look like a legitimate software vendor — because we are one. 🔥❄️
|
||||
|
||||
— Michael + Claude (Chronicler #83 — The Compiler)
|
||||
Reference in New Issue
Block a user