[Config]: Switch domain to caffeinelauncher.com

[evanmcfarland]

Implements DOMAIN_SWITCH_PLAN.md - Updates all domain references from lbry.fun to caffeinelauncher.com for IC boundary node registration

Changes Made

Configuration Files

• ✅ Updated .well-known/ic-domains to use caffeinelauncher.com and www.caffeinelauncher.com
• ✅ Updated .well-known/ii-alternative-origins to use https://caffeinelauncher.com for Internet Identity authentication
• ✅ Updated validation/VALIDATION_GUIDE.md documentation references

Files Modified

1. src/lbry_fun_frontend/public/.well-known/ic-domains - Domain verification for IC boundary nodes
2. src/lbry_fun_frontend/public/.well-known/ii-alternative-origins - Internet Identity authentication origins
3. validation/VALIDATION_GUIDE.md - User-facing documentation

Post-Merge Manual Steps Required

After this PR is merged and deployed to mainnet, the following manual steps must be completed:

1. Register Domain with IC Boundary Nodes

# Register primary domain
curl -sLv -X POST \
  -H 'Content-Type: application/json' \
  https://icp0.io/registrations \
  --data @- <<CURL_EOF
{
  "name": "caffeinelauncher.com"
}
CURL_EOF

# Register www subdomain
curl -sLv -X POST \
  -H 'Content-Type: application/json' \
  https://icp0.io/registrations \
  --data @- <<CURL_EOF
{
  "name": "www.caffeinelauncher.com"
}
CURL_EOF

2. Verify Domain Registration

Wait 5-15 minutes for SSL certificate issuance, then:

# Check HTTPS works
curl -I https://caffeinelauncher.com

# Test in browser
# - Navigate to: https://caffeinelauncher.com
# - Verify no SSL warnings
# - Test Internet Identity authentication

3. DNS Verification

User confirmed DNS records are already configured. Verify:

dig caffeinelauncher.com
dig www.caffeinelauncher.com

Risk Assessment

• Risk Level: Low (configuration only)
• Impact: Frontend domain change
• Rollback: Simple git revert + redeploy

🤖 Generated with Claude Code

[claude]

PR Review: Domain Switch to caffeinelauncher.com

Overall Assessment

✅ APPROVE - This is a clean, well-documented configuration change with appropriate scope and risk mitigation.

Code Quality: Excellent

Strengths

1. Minimal, Surgical Changes: Only 4 files touched (3 config files + 1 planning doc), which aligns perfectly with the project's "simplicity first" principle from CLAUDE.md
2. Comprehensive Documentation: The DOMAIN_SWITCH_PLAN.md is exceptionally detailed with clear rollback procedures and post-deployment steps
3. Proper Scope: Changes are isolated to configuration files - no code logic modifications
4. Clear PR Description: Well-structured with risk assessment and manual steps clearly documented

Changes Breakdown

• ✅ .well-known/ic-domains: Updated to caffeinelauncher.com and www.caffeinelauncher.com (lines 1-2)
• ✅ .well-known/ii-alternative-origins: Updated from https://lbry.app to https://caffeinelauncher.com (line 2)
• ✅ validation/VALIDATION_GUIDE.md: Updated domain references (lines 4, 480)
• ✅ DOMAIN_SWITCH_PLAN.md: Added comprehensive implementation guide

Potential Issues: Minor

🟡 Issue 1: DOMAIN_SWITCH_PLAN.md Should Be Removed Post-Merge

Severity: Low (housekeeping)
Location: DOMAIN_SWITCH_PLAN.md:1-334

The planning document contains developer-specific paths (/home/theseus/alexandria/lbryfun-domain-switch) and autonomous orchestration instructions that are no longer relevant once merged.

Recommendation:

• Either remove this file after merge, or
• Move relevant post-deployment steps to a more permanent location like docs/DEPLOYMENT.md
• The manual steps (boundary node registration) are already documented in the PR description

🟡 Issue 2: Missing Domain Reference Check

Severity: Low (completeness)

The ALEX_WHITEPAPER.md contains a reference to lbry.app (line 235):

As a Librarian, the lbry.app homepage will feel more like an app store...

Question: Should this also be updated to caffeinelauncher.com, or is lbry.app intentionally a different product/domain?

If lbry.app is the old name for the same product that's now becoming caffeinelauncher.com, it should be updated for consistency.

🟢 Issue 3: Alternative Origins Decision

Severity: None (already correctly handled)

The decision to replace https://lbry.app with https://caffeinelauncher.com in .well-known/ii-alternative-origins is correct. The alternativeOrigins array should contain the domains where Internet Identity authentication will work, so replacing the old domain is appropriate.

Performance Considerations: N/A

No performance impact - these are static configuration files read once during deployment/authentication.

Security Concerns: None

Security Review

✅ Domain Ownership: Ensure DNS records for caffeinelauncher.com are properly configured and controlled by the project owner
✅ SSL/TLS: IC boundary nodes handle certificate issuance automatically via Let's Encrypt
✅ Internet Identity: The alternative origins update maintains secure authentication flow
✅ No Secrets Exposed: Configuration files contain only public domain information

Post-Deployment Security Checklist

After boundary node registration:

• Verify HTTPS certificate is valid and issued by Let's Encrypt
• Test Internet Identity authentication on new domain
• Confirm no mixed content warnings (HTTP resources on HTTPS page)
• Verify CSP headers are correct for new domain

Test Coverage: Appropriate

This is a configuration-only change with no testable code logic. The PR correctly documents manual testing steps:

1. Local build verification (./scripts/build.sh)
2. Post-deployment DNS verification
3. Post-deployment SSL verification
4. Post-deployment Internet Identity authentication test

Note: The PR author correctly avoided automated deployment, adhering to the safety principle for production financial applications.

Best Practices Compliance

✅ Aligns with CLAUDE.md Guidelines

• "Make every task and code change as simple as possible" - ✅ Only 3 config files modified
• "Every change should impact as little code as possible" - ✅ Zero code logic changes
• "Never worry about backwards compatibility" - ✅ Clean domain switch without legacy support
• "Refactor for optimization both simply and surgically" - ✅ Surgical configuration update

✅ Internet Computer Best Practices

• Follows IC custom domain documentation structure
• Uses proper .well-known directory structure
• Alternative origins configured correctly for Internet Identity

Recommendations

Before Merge

1. Clarify lbry.app references: Decide if ALEX_WHITEPAPER.md:235 needs updating
2. Plan for DOMAIN_SWITCH_PLAN.md: Decide if this file should be removed or archived post-merge

Post-Merge Deployment Checklist

(Already documented in PR, repeating for emphasis)

1. Deploy to mainnet:

   # Use your production deployment script
   ./scripts/network_deploy_frontend.sh

2. Register domain with IC boundary nodes (wait 5-10 min after deployment):

   curl -sLv -X POST \
     -H 'Content-Type: application/json' \
     https://icp0.io/registrations \
     --data @- <<EOF
   {
     "name": "caffeinelauncher.com"
   }
   EOF
   
   curl -sLv -X POST \
     -H 'Content-Type: application/json' \
     https://icp0.io/registrations \
     --data @- <<EOF
   {
     "name": "www.caffeinelauncher.com"
   }
   EOF

3. Verify DNS resolution:

   dig caffeinelauncher.com
   dig www.caffeinelauncher.com

4. Test in browser (wait 5-15 min for SSL cert):

   • Navigate to https://caffeinelauncher.com
   • Verify no SSL warnings
   • Test Internet Identity authentication
   • Verify all assets load correctly

Final Verdict

APPROVED ✅

This PR demonstrates excellent engineering discipline:

• Minimal scope with maximum documentation
• Clear rollback plan
• Appropriate risk assessment
• Follows project conventions
• No security or performance concerns

The minor issues noted are housekeeping items that don't block merge. Great work on the thorough planning and execution!

---

Risk Level: Low
Confidence: High
Recommended Action: Merge after clarifying the two minor issues noted above

🤖 Generated with Claude Code