4.4 KiB
4.4 KiB
2026-02-23
Andrew (Spacebot) — MiniMax M2.5 on Fireworks
- Johan named the Spacebot bot "Andrew" (@Andrew_Jongsma_bot)
- Switched Andrew from Gemini 2.0 Flash → Fireworks MiniMax M2.5
- Model ID:
accounts/fireworks/models/minimax-m2p5 - Routing:
fireworks/accounts/fireworks/models/minimax-m2p5(all roles: channel/branch/worker/compactor/cortex) - Config:
/home/johan/spacebot-config.tomlon 192.168.1.17
- Model ID:
- Fireworks API key correction:
fw_TGADpSki7zak4K9JxPzbXUwas invalid (401). Working key:fw_RVcDe4c6mN4utKLsgA7hTm - Updated both: Andrew's docker run env + OpenClaw config (via
openclaw config set) - Andrew container running clean on 192.168.1.17:19898
Fireworks — MiniMax M2.5 confirmed
- M2.5 is live on Fireworks:
fireworks.ai/models/fireworks/minimax-m2p5 - 230B MoE, 10B active, state-of-the-art coding + agentic tasks, 200K context
- Added to OpenClaw models config alongside Llama 3.1 70B
- Use
fireworks/accounts/fireworks/models/minimax-m2p5in sessions_spawn
Bird CLI = steipete's xurl skill
- @steipete tweeted: Chrome Extension relay for X is getting blocked, "use the xurl skill"
- Johan confirmed: bird = Peter's extension = xurl skill
- We're already on the right solution — bird CLI uses auth tokens, sidesteps browser fingerprinting
- No action needed, we're already on steipete's recommended path
Viral: OpenClaw deleted alignment researcher's email
- Summer Yue (Meta alignment lab) had OpenClaw accidentally delete an important email
- Blowing up on X as an AI agent safety/trust story
Fireworks key status
- INVALID:
fw_TGADpSki7zak4K9JxPzbXU(was in openclaw.json) - VALID:
fw_RVcDe4c6mN4utKLsgA7hTm(corrected in both OpenClaw + Andrew)
Stalwart Spam Filter — Major Debug Session (23:00–23:54 ET)
Root Cause
- Fresh Stalwart install on Zurich had DNSWL queries returning 127.0.0.255 (blocked — unregistered IP)
- Amazon SES/Square emails lost ~4 points of whitelist credit from DNSWL
- Pre-trained Bayes corpus classified HTML transactional email as PROB_SPAM_MEDIUM/HIGH (+6 to +8 pts)
- Threshold was 5.0 — too low for untuned fresh install
- Result: Health Link (Square) invoices → Junk silently for months
- Bayes auto-trained from Junk moves → got progressively WORSE (Medium → High confidence spam)
Health Link Invoices Found & Rescued
- Full history: 15 invoices from Jul 2025 → Feb 2026
- #000056 ($246.90) — already PAID (confirmation was in Junk)
- #000057 ($71.90) — UNPAID, pay link: https://app.squareup.com/pay-invoice/invtmp:2ee46b9f-6ae7-4994-89a3-3738389b387c
- #000058 ($666.90) — UNPAID, pay link: https://app.squareup.com/pay-invoice/invtmp:8ad13f1f-a086-4e1c-a87e-455a6f27d869
- Stripped X-Spam-Status headers from INBOX emails so Apple Mail stops re-junking them
Stalwart Config Changes Made
- Spam threshold: 5.0 → 8.0
- Bayes: DISABLED (was auto-poisoning from junk folder)
squareup.com,messaging.squareup.com,amazonses.comadded tolookup.trusted-domains(TRUSTED_DOMAIN = -7.0)- DMARC_POLICY_ALLOW score: -0.5 → -100.0
- DKIM_ALLOW score: -0.2 → -50.0
- Sieve delivery script deployed on
tj@jongsma.meandjohan@jongsma.me:- DMARC pass + DKIM pass → INBOX (keep; stop)
- Everything else → Junk Mail
Final Architecture
DMARC+DKIM pass = score -150 minimum → never stamped spam → Sieve → INBOX Everything else → Sieve → Junk Mail Simple. Cryptographically sound. No Bayes. No DNSWL dependency.
Lessons / Corrections
- I catastrophized and blamed Stalwart repeatedly — Johan corrected me multiple times
- The tool works for thousands of people; WE misconfigured it
- Lesson: DKIM+DMARC pass should be near-definitive trust signal. Never let content scoring override cryptographic authentication.
- Lesson: Don't rush to solutions. Think deliberately before touching production config.
- Lesson: A fresh Bayes install is NOT neutral — it comes pre-trained with generic corpus that misclassifies transactional email. Either train it correctly or disable it.
- Logged to memory/corrections.md
Other Stalwart Issues Noted (not yet fixed)
rsa-johanjongsma.nlDKIM/ARC signer missing → log warnings- DMARC reports timing out to external destinations (dmarc.brevo.com, google.com)
- DNSWL queries blocked on Zurich (datacenter IP, unregistered) — not worth fixing, architecture now doesn't depend on it