# Council Briefing: 2025-07-28

## Monthly Goal

Current focus: Stabilize and attract new users to auto.fun by showcasing 24/7 agent activity (streaming, trading, shitposting), ship production ready elizaOS v2.

## Daily Focus

- Significant technical infrastructure progress with containerized architecture and browser extension development, alongside growing community engagement for Eli5 and governance implementation.

## Key Points for Deliberation

### 1. Topic: Containerized Architecture Evolution

**Summary of Topic:** Shaw reported significant progress on a containerized application architecture enabling Eliza to run with Tauri through websockets, PostgreSQL, and Ollama, creating a fully local agent application with self-installation capabilities for cross-platform compatibility.

#### Deliberation Items (Questions):

**Question 1:** How should we prioritize this containerized architecture approach in relation to our current monthly goal of shipping production-ready elizaOS v2?

  **Context:**
  - `Shaw reported significant progress on a containerized application that enables Eliza to run with Tauri through websockets, PostgreSQL and Ollama, creating a fully local agent application that self-installs Podman if Docker isn't available.`
  - `Shaw shared progress on a game implementation with working container and lifecycle components built in an 'App store friendly way,' noting that moving containers to cloud could enable iPhone compatibility.`

  **Multiple Choice Answers:**
    a) Fast-track it as a core v2 feature since it dramatically improves cross-platform compatibility and local deployment options.
        *Implication:* Resources would shift toward containerization, potentially delaying other v2 features but delivering a more deployable solution.
    b) Integrate it as an optional deployment pattern while maintaining focus on core v2 functionality.
        *Implication:* Balances innovation with existing roadmap commitments, allowing both approaches to progress in parallel.
    c) Designate it as a post-v2 enhancement to avoid scope creep and maintain focus on our monthly goals.
        *Implication:* Preserves focus on immediate v2 deliverables but risks missing an opportunity to improve deployment flexibility.
    d) Other / More discussion needed / None of the above.

**Question 2:** How should we leverage the potential 'App store friendly' nature of this containerized approach to support our auto.fun user acquisition strategy?

  **Context:**
  - `Shaw shared progress on a game implementation with working container and lifecycle components built in an 'App store friendly way,' noting that moving containers to cloud could enable iPhone compatibility.`

  **Multiple Choice Answers:**
    a) Accelerate iOS/mobile development to create a fully-featured auto.fun mobile experience for mainstream crypto users.
        *Implication:* Expands potential user base but requires significant development resources and App Store navigation.
    b) Create a simplified mobile companion app focusing only on monitoring agent activities and notifications.
        *Implication:* Provides mobile visibility with lower development overhead, serving as a gateway to the full desktop experience.
    c) Focus on progressive web app improvements rather than native apps to maintain development velocity.
        *Implication:* Avoids App Store approval complexities but potentially limits mobile engagement opportunities.
    d) Other / More discussion needed / None of the above.

---


### 2. Topic: Browser Extension Strategic Direction

**Summary of Topic:** cjft is developing an Eliza browser extension to overcome automation limitations with puppeteer/playwright, providing more stable browser integration without Google Cloud API dependencies, raising questions about strategic positioning of this capability.

#### Deliberation Items (Questions):

**Question 1:** How should browser extension capabilities be positioned within our product ecosystem?

  **Context:**
  - `cjft is working on an Eliza browser extension to overcome automation limitations with puppeteer/playwright, providing more stable browser integration without Google Cloud API dependencies.`
  - `cjft suggested that '/extension' could become a core package exposing global services to all plugins.`

  **Multiple Choice Answers:**
    a) As a core elizaOS feature for all agents, emphasizing universal browser integration capabilities.
        *Implication:* Makes browser interaction a fundamental capability but increases core complexity and maintenance burden.
    b) As an optional extension primarily targeting developers and power users for specialized automation.
        *Implication:* Keeps the core simpler while still providing advanced capabilities for those who need them.
    c) As a specialized product focused on Web3 use cases like wallet integration and dApp interaction.
        *Implication:* Creates a more focused value proposition for crypto users but limits broader application.
    d) Other / More discussion needed / None of the above.

**Question 2:** What authentication model should we adopt for the browser extension to balance security and usability?

  **Context:**
  - `What makes the browser extension approach better than puppeteer/playwright? It simplifies automation, avoids Google Cloud API dependencies, overcomes authentication challenges, and provides more stable browser integration capabilities.`

  **Multiple Choice Answers:**
    a) Implement a standalone authentication system specific to the extension with its own credentials.
        *Implication:* Provides highest security isolation but creates friction with separate login requirements.
    b) Use shared authentication with the elizaOS main application, providing seamless integration.
        *Implication:* Offers better user experience but increases potential attack surface if credentials are compromised.
    c) Adopt a hybrid approach where basic functions work without authentication but sensitive operations require verification.
        *Implication:* Balances convenience and security but creates a more complex permission model to communicate to users.
    d) Other / More discussion needed / None of the above.

---


### 3. Topic: Governance Implementation and Token Utility

**Summary of Topic:** Governance development is actively progressing with token holder snapshots and a working voting system, alongside community questions about benefits for AI16Z token holders, highlighting the need to articulate clear token utility.

#### Deliberation Items (Questions):

**Question 1:** What should be the first governance capabilities offered to AI16Z token holders?

  **Context:**
  - `Wire mentioned that 'governance is being built' and directed users to read a post by Jin on X (Twitter) for more information.`
  - `Jin reported taking 'another snapshot of token holders' and confirmed that a voting system is now working.`
  - `What will holders receive for holding $ai16z? (asked by Dean999) A: Unanswered`

  **Multiple Choice Answers:**
    a) Protocol parameter voting on key ecosystem variables and treasury allocations.
        *Implication:* Gives token holders direct influence over protocol behavior but may slow decision-making on technical matters.
    b) Feature prioritization voting to help guide product roadmap decisions.
        *Implication:* Balances community input with maintainer discretion while keeping technical implementation decisions with the core team.
    c) Community fund allocation voting for grants and ecosystem development initiatives.
        *Implication:* Focuses governance on ecosystem growth rather than protocol parameters, potentially creating more visible value creation.
    d) Other / More discussion needed / None of the above.

**Question 2:** Beyond governance, what additional utility should be prioritized for AI16Z token holders to drive value and adoption?

  **Context:**
  - `What will holders receive for holding $ai16z? (asked by Dean999) A: Unanswered`
  - `Q: What happens August 1st? (asked by cantseemenomore) A: green light for alt coin season (answered by Railgun)`

  **Multiple Choice Answers:**
    a) Fee discounts and premium features for auto.fun and other elizaOS services based on token holdings.
        *Implication:* Creates direct utility tied to ecosystem usage but may limit adoption if core features require tokens.
    b) Revenue sharing from auto.fun launchpad fees distributed to token stakers.
        *Implication:* Provides passive income potential but creates regulatory considerations regarding security classification.
    c) Access to exclusive AI agents and capabilities proportional to token holdings.
        *Implication:* Directly ties token value to AI capability access, creating a tiered service model based on holdings.
    d) Other / More discussion needed / None of the above.