# Council Briefing: 2025-01-12

## Monthly Goal

December 2025: Execution excellence—complete token migration with high success rate, launch ElizaOS Cloud, stabilize flagship agents, and build developer trust through reliability and clear documentation.

## Daily Focus

- Stability triage dominated the cycle: the 0.1.8 release landed alongside a surge of fixes (Twitter, Postgres/Supabase, install/lockfile) but also exposed DX fragility that threatens the “trust through shipping” mandate.

## Key Points for Deliberation

### 1. Topic: 0.1.8 Stabilization vs. Installer Friction (DX Gate)

**Summary of Topic:** We shipped 0.1.8 and immediately absorbed install and build regressions (pnpm lockfile, Docker build failures, Windows compatibility), indicating our release process is outrunning our “reliable by default” standard. The Council must decide how hard we pivot from feature velocity to hardening workflows and supported environments.

#### Deliberation Items (Questions):

**Question 1:** Do we declare a short “stability freeze” (no new plugins/features) until install + build succeeds reliably across the top environments (Linux, macOS, Windows/WSL, Docker)?

  **Context:**
  - `Discord 2025-01-11: “Windows Build Issues… WSL appears to work better.”`
  - `GitHub issues (daily summary): “pnpm installation and startup errors (Issue #2203)”, “Outdated lockfile errors with pnpm (Issue #2215)”, “Docker image build failures (Issue #2192)”`

  **Multiple Choice Answers:**
    a) Yes—announce a stability freeze and ship only bugfixes + docs for 1–2 sprints.
        *Implication:* Reinforces execution excellence and reduces churn, at the cost of slowing ecosystem feature hype.
    b) Partial freeze—block new core changes, allow additive plugins behind clearer quality gates.
        *Implication:* Maintains ecosystem growth while reducing breakage risk, but requires strong CI/publishing discipline.
    c) No—continue velocity and rely on community patches as issues surface.
        *Implication:* Maximizes short-term expansion, but risks compounding reliability debt and eroding developer trust.
    d) Other / More discussion needed / None of the above.

**Question 2:** What is the Council’s canonical “supported” runtime matrix for the next release line, and what do we explicitly label as best-effort?

  **Context:**
  - `Discord 2025-01-11: users report Windows build issues; WSL guidance circulated (quixotechdon).`
  - `PR #1760: “improve Windows compatibility for Vite dev server” (indicates active Windows pain).`

  **Multiple Choice Answers:**
    a) Officially support Linux/macOS + Docker; Windows only via WSL2 (documented as primary path).
        *Implication:* Sets realistic expectations and reduces support burden while preserving Windows accessibility.
    b) Officially support native Windows builds as first-class (dedicated CI runners + maintainer ownership).
        *Implication:* Improves adoption in enterprise/dev audiences but increases maintenance load and CI complexity.
    c) Support everything “community best-effort,” with no guarantees beyond mainline Linux.
        *Implication:* Minimizes core obligations, but conflicts with “developer-friendly” positioning and hurts credibility.
    d) Other / More discussion needed / None of the above.

**Question 3:** Which release-quality mechanisms do we institutionalize to prevent lockfile/Docker regressions from reaching main?

  **Context:**
  - `GitHub issues: “Lock file errors and missing dependencies (Issue #2183)”, “Docker image build failures (Issue #2192)”.`
  - `PRs: multiple rapid release-prep/build hotfixes (e.g., #2194, #2184) indicate reactive release hardening.`

  **Multiple Choice Answers:**
    a) Add strict merge gates: reproducible install, docker build, and smoke tests must pass on PR and merge queue.
        *Implication:* Cuts regressions sharply but slows merges and demands stable CI infrastructure.
    b) Adopt staged releases (alpha/beta) with canary Docker images; only promote after community validation.
        *Implication:* Balances speed and safety, but needs clear channeling and communications discipline.
    c) Keep current approach; rely on quick follow-up hotfix releases post-merge.
        *Implication:* Preserves velocity but normalizes instability and increases support overhead.
    d) Other / More discussion needed / None of the above.

---


### 2. Topic: Social Client Reliability (Twitter) as a Trust Signal

**Summary of Topic:** Twitter integration remains a recurring failure point (auth hostility, rate limiting, JSON formatting, deduplication), and is effectively our public-facing stability demo. Fixes are landing, but the Council must decide whether to pivot to official API support, enforce stronger defaults, or provide approval workflows to reduce reputational risk.

#### Deliberation Items (Questions):

**Question 1:** Do we prioritize an “official Twitter API” path (developer keys) even if it reduces out-of-box ease, to improve reliability and compliance?

  **Context:**
  - `Discord 2025-01-11 Action Items: “Support for official Twitter API with developer keys to avoid restrictions (eschnou).”`
  - `Discord FAQ 2025-01-11: auth failures; “datacenter IPs may cause Twitter to be more hostile toward your account.”`

  **Multiple Choice Answers:**
    a) Yes—make official API the default recommended path; keep scraper-based method as fallback.
        *Implication:* Improves reliability and reduces platform bans, but raises onboarding friction and cost.
    b) Hybrid—support both equally, with auto-detection and clear warnings for non-API mode.
        *Implication:* Preserves accessibility while improving safety signaling, at the cost of maintaining two paths.
    c) No—stay primarily scraper/session-based for maximum openness and minimize dependency on API keys.
        *Implication:* Keeps onboarding easy but perpetuates unpredictable breakage and reputational incidents.
    d) Other / More discussion needed / None of the above.

**Question 2:** What is the Council’s preferred default for outbound-post safety: fully autonomous posting, or an approval workflow (human-in-the-loop) for public channels?

  **Context:**
  - `PR #1876: “Add approval mechanism for Twitter posts via Discord bot.”`
  - `3d-ai-tv channel: “Anything said on the show is considered an endorsement… careful content filtering required.”`

  **Multiple Choice Answers:**
    a) Default to approval workflow for public accounts; allow autonomous mode only via explicit opt-in.
        *Implication:* Reduces endorsement risk and bans, but weakens the “autonomous agent” wow factor.
    b) Default to autonomous posting with strict rate limits + safe templates; add optional approvals for sensitive accounts.
        *Implication:* Preserves autonomy while adding guardrails, but still risks sporadic public failures.
    c) Run fully autonomous by default; treat mishaps as acceptable “frontier agent” cost.
        *Implication:* Maximizes virality but threatens developer trust and may invite platform enforcement.
    d) Other / More discussion needed / None of the above.

**Question 3:** How do we standardize Twitter behavior to minimize breakage while keeping customization power for advanced builders?

  **Context:**
  - `Discord 2025-01-11: JSON formatting bug fixes discussed; templates.ts edits recommended (masterdai).`
  - `Daily report: “Fixed Twitter plugin prompt to ensure JSON returns (#2196)” and “mention deduplication cleanup (#2185).”`

  **Multiple Choice Answers:**
    a) Centralize tweet/reply generation into a single, well-tested template system with strict output validation.
        *Implication:* Improves consistency and reduces incidents, but may constrain creative formatting without extension hooks.
    b) Provide “profiles” (safe defaults) plus advanced overrides in character.json, with warnings and lint checks.
        *Implication:* Balances DX and power; requires building configuration linting and documentation.
    c) Keep current flexible approach; rely on community snippets and ad-hoc fixes.
        *Implication:* Moves fastest short-term but keeps support burden high and outcomes inconsistent.
    d) Other / More discussion needed / None of the above.

---


### 3. Topic: Ecosystem Trust & Tokenomics Coherence (Tribute + Launchpad)

**Summary of Topic:** Community trust is strained by leadership/conflict optics (AICC fallout, DegenAI token sale by a core dev) while tokenomics design remains unsettled (tribute enforcement, launchpad base pair). The Council must align technical shipping with governance clarity to prevent “ecosystem drift” from undermining adoption.

#### Deliberation Items (Questions):

**Question 1:** What is our immediate trust-repair protocol when core contributors’ token behavior triggers community alarm (e.g., DegenAI sale event)?

  **Context:**
  - `Discord 2025-01-11: “DegenAI Trust Issues… Skely… sold all his DegenAI tokens, causing significant trust concerns.”`
  - `Discord 2025-01-10: “Trust rebuilding… ‘launching a memecoin = fired’ policy mentioned by Shaw.”`

  **Multiple Choice Answers:**
    a) Publish a formal disclosure + conduct policy (vesting, trading windows, transparency norms) for core contributors.
        *Implication:* Signals maturity and stabilizes perception, but requires enforcement and may deter some contributors.
    b) Handle case-by-case with informal explanations and community Q&A sessions.
        *Implication:* Lower overhead, but risks inconsistency and repeated credibility shocks.
    c) Explicitly separate protocol development from token-affiliated projects; avoid any policing of contributor behavior.
        *Implication:* Reduces governance scope, but leaves the community without guardrails and fuels rumor cycles.
    d) Other / More discussion needed / None of the above.

**Question 2:** For the planned launchpad, what base pair should be the default liquidity anchor to maximize ecosystem growth while supporting token value narrative?

  **Context:**
  - `Discord tokenomics channel: debate “ai16z vs SOL as base pair”; plur_daddy argues for ‘monetary premium’; eskender.eth prefers SOL for reduced friction.`
  - `Discord 2025-01-11: “Plans for Q1 launch of a launchpad similar to Virtuals.”`

  **Multiple Choice Answers:**
    a) Default SOL base pair; optionally create secondary AI16Z pools for aligned projects.
        *Implication:* Maximizes liquidity and onboarding ease; token value accrual shifts to fees/buybacks rather than forced pairing.
    b) Default AI16Z base pair to create monetary premium; SOL pools only as secondary routing.
        *Implication:* Strengthens token-centric narrative but may add friction and reduce launchpad throughput.
    c) Dual-pool standard at launch (SOL:Token and AI16Z:Token) with configurable splits.
        *Implication:* Balances both camps but increases complexity and operational overhead for every launch.
    d) Other / More discussion needed / None of the above.

**Question 3:** How strictly should we enforce the 10% tribute model, given enforcement is easy on-launchpad but difficult off-platform?

  **Context:**
  - `Discord tokenomics: “Launchpad doesn’t deprecate tribute; it’s additive thinking (jin).”`
  - `Discord tokenomics action items: “Develop a system to LP the tokens sent to the DAO through tribute (jin).”`

  **Multiple Choice Answers:**
    a) Enforce tribute only for launchpad-origin projects; offer strong incentives (distribution, listing, tooling) to make compliance voluntary elsewhere.
        *Implication:* Keeps the system open and composable while still building a meaningful aligned subset.
    b) Attempt broader enforcement via certification/badges and preferential discovery; non-tribute projects are de-ranked.
        *Implication:* Creates a strong funnel toward alignment but risks accusations of gatekeeping and may fragment the ecosystem.
    c) De-emphasize tribute in favor of usage-based fees (cloud/runtime) and focus tokenomics on service revenue.
        *Implication:* Simplifies enforcement and ties value to real usage, but requires product monetization readiness and clarity.
    d) Other / More discussion needed / None of the above.