# Council Briefing: 2025-08-09 ## 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 - ElizaOS development has stabilized with release of version 1.4.2, fixing critical issues that were blocking developers and implementing significant architectural improvements to support streaming and client communication. ## Key Points for Deliberation ### 1. Topic: Version Stability and Technical Debt **Summary of Topic:** The team has successfully resolved critical build issues and compatibility problems across versions, releasing v1.4.2 which addresses key technical debt while implementing foundational improvements for future development. #### Deliberation Items (Questions): **Question 1:** How should we balance rapid iteration with technical stability as we approach production-ready v2? **Context:** - `A critical logger-related bug was identified that broke the entire ecosystem, stemming from a package.json update that changed dependency versions.` - `Users reported issues when updating from version 0.1.9 to newer versions (1.x), particularly with actions that previously triggered consistently no longer working due to behavioral changes in newer Eliza core versions.` **Multiple Choice Answers:** a) Institute stricter release criteria with mandatory code reviews and integration testing before any version bump. *Implication:* This will slow development velocity but ensure higher stability for users and reduce support burden. b) Maintain current agile approach but improve automated testing infrastructure with comprehensive regression tests. *Implication:* This balances development speed with quality assurance, requiring investment in testing but preserving iteration speed. c) Create a parallel 'LTS' branch with slower releases and backported fixes alongside the rapid development branch. *Implication:* This addresses both stability needs for production users and innovation needs for developers, but increases maintenance overhead. d) Other / More discussion needed / None of the above. **Question 2:** What should be our policy regarding breaking changes in minor version updates as we approach v2? **Context:** - `Christopher reported that after updating from version 0.1.9 to a newer version (likely 1.x), actions that previously triggered consistently no longer work.` - `sayonara suggested improving descriptions/examples and trying version 1.4.2 latest.` **Multiple Choice Answers:** a) Strictly adhere to semantic versioning with breaking changes only in major versions, even if it means delaying improvements. *Implication:* This provides maximum stability for users but may slow down architectural improvements needed for v2. b) Allow breaking changes in minor versions but provide comprehensive migration guides and extended deprecation warnings. *Implication:* This accelerates development toward v2 while giving users clear pathways to adapt to changes. c) Create backwards compatibility layers to support previous behavior while enabling new improvements under the hood. *Implication:* This maintains compatibility but increases code complexity and potential performance overhead. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Architecture and Performance Optimization **Summary of Topic:** Significant technical discussions revealed architecture limitations in the current token-by-token streaming implementation, with the team planning to rethink client communication to support both SSE and websockets for improved efficiency. #### Deliberation Items (Questions): **Question 1:** How should we prioritize streaming implementation optimization versus other feature development for v2? **Context:** - `Detailed technical discussion about inefficiencies in the current token-by-token streaming implementation using event emitters versus native HTTP streaming (SSE/chunked). The current approach could cause latency issues, CPU overhead, and memory problems.` - `Team discussed the need to rethink and remake the client communication layer, supporting both SSE and websockets from the server.` **Multiple Choice Answers:** a) Make streaming optimization the top priority as it directly impacts user experience and system scalability. *Implication:* This ensures our core functionality is robust and performant but may delay other features needed for auto.fun. b) Balance streaming improvements with auto.fun-specific features, implementing incremental optimizations. *Implication:* This addresses both technical debt and business goals, but results in slower progress on both fronts. c) Focus on auto.fun feature completeness first, then address streaming optimization as part of the v2 finalization. *Implication:* This prioritizes user acquisition and product-market fit but leaves performance issues unresolved longer. d) Other / More discussion needed / None of the above. **Question 2:** What architectural approach should we take for identity verification and user trust across platforms? **Context:** - `Implement "identity-mapper" or "Rolodex" for verifying users across different platforms (Mentioned by cjft)` - `Develop a trust system for identity verification across platforms (Mentioned by Odilitime)` **Multiple Choice Answers:** a) Develop a centralized identity service with verification credentials that can be used across all elizaOS projects. *Implication:* This creates a uniform solution but introduces centralization that conflicts with our decentralization values. b) Implement a decentralized identity protocol with reputation scores stored on-chain, compatible with existing Web3 standards. *Implication:* This aligns with our decentralization principles but may create friction for Web2 users and increase complexity. c) Create a hybrid approach where basic verification is lightweight but additional trust levels can be earned through on-chain actions. *Implication:* This balances usability with security but requires careful UX design to avoid confusion. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Market Positioning and Competitive Strategy **Summary of Topic:** Community discussions highlight concerns about project valuation compared to competitors like Virtuals, with suggestions to implement measures preventing projects from building on Eliza but launching elsewhere. #### Deliberation Items (Questions): **Question 1:** How should we address the valuation gap between Eliza/AI16z ($140M) and competitors like Virtuals ($800-900M)? **Context:** - `Comparison of project valuation to Vercel (maker of v0), with suggestions that AI16z is undervalued. Discussion about closing the valuation gap with Virtuals (valued at 800-900 million vs AI16z at 140 million).` - `Suggestion to prevent projects from building on Eliza and then launching on Virtuals to protect valuation.` **Multiple Choice Answers:** a) Focus purely on technical excellence and user growth, letting market valuation follow organically. *Implication:* This maintains product focus but may leave financial value on the table in the short term. b) Implement token capturing mechanisms and exclusivity features that ensure projects built on elizaOS contribute to token value. *Implication:* This directly addresses valuation concerns but may create friction for early adopters and conflict with open-source ethos. c) Launch aggressive marketing and BD initiatives highlighting our competitive advantages and showcasing auto.fun success stories. *Implication:* This raises awareness and potentially valuation but diverts resources from product development. d) Other / More discussion needed / None of the above. **Question 2:** What commercial model best balances our open-source ethos with sustainable value capture? **Context:** - `Suggestion to prevent projects from building on Eliza and then launching on Virtuals to close valuation gap (Mentioned by phetrusarthur✈)` - `Confirmation that the move to Eliza from AI16z and DAO governance has already happened.` **Multiple Choice Answers:** a) Maintain pure open-source approach but build premium services on top that capture value (hosting, monitoring, specialized agents). *Implication:* This preserves open-source principles but may limit value capture to service margins rather than protocol value. b) Implement a token-based licensing model where commercial usage requires token staking proportional to usage volume. *Implication:* This creates direct token utility and value capture but may limit adoption among commercial entities. c) Create a hybrid where core remains open but advanced features and integrations require participation in the token economy. *Implication:* This balances openness with value capture but requires careful feature segmentation to be effective. d) Other / More discussion needed / None of the above.