Missing runtime-loadable chat channel plugins (vs OpenClaw channel SDK)

[Dhivya-Bharathy]

Summary

Missing capability: New chat channels are added by core code under src/praisonai/praisonai/bots/. There is no loadable channel plugin mechanism comparable to OpenClaw’s channel plugin SDK and distribution/community story. MCP/webhooks can approximate integrations but do not match in-process channel plugins.

Comparison

OpenClaw	PraisonAI today
SDK + installable channel plugins	In-tree bots + MCP; no stable third-party channel plugin ABI

Expected engineering outcomes (acceptance)

• Design: plugin manifest, entrypoint, lifecycle, versioning — or wontfix with “use MCP only” signed off by maintainers.
• Code deliverable (preferred): minimal hello-world channel plugin loaded at runtime (feature-flagged) with tests; or epic split into tracked sub-issues linked from here.
• Close with runtime loading path (even experimental) or explicit architectural rejection (maintainer decision).

References (external)

• https://docs.openclaw.ai/plugins/sdk-overview
• https://docs.openclaw.ai/plugins/sdk-channel-plugins
• https://docs.openclaw.ai/plugins/community

Notes

Marketplace operations (payments, review queue) are out of scope until a technical load path exists.

[praisonai-triage-agent]

👋 Thanks for opening this issue, @Dhivya-Bharathy!

A maintainer will review this shortly. In the meantime:

• Make sure you've included steps to reproduce (for bugs)
• Check existing issues for duplicates
• Review the documentation for related guides

A maintainer can trigger deeper analysis by commenting @claude on this issue.

[praisonai-triage-agent]

Claude finished @praisonai-triage-agent[bot]'s task —— View job

---

Channel Plugin Architecture Analysis & Decision

I've analyzed PraisonAI's current architecture and the OpenClaw channel plugin model. Here's my architectural assessment and recommendation.

Todo List:

• Setup git identity and auth
• Read AGENTS.md for architecture validation
• Analyze current bot implementation structure
• Review existing MCP and plugin architecture
• Apply architecture routing rules (CORE vs WRAPPER vs TOOLS vs DOCS vs PLUGINS)
• Make architectural decision on channel plugin SDK vs status quo
• Document decision and recommended patterns

---

🏛️ Architectural Analysis

Current PraisonAI Bot Architecture:

BotOS (praisonai wrapper)  ← Multi-platform orchestrator  
├── Bot (praisonai wrapper)  ← Platform-agnostic wrapper
│   └── TelegramBot/DiscordBot/SlackBot/etc. (praisonai wrapper)
└── BotProtocol (praisonaiagents core) ← Lightweight interface
    └── Agent/AgentTeam (praisonaiagents core) ← AI brain

Architecture Routing Decision:

• Current bots: ✅ WRAPPER layer (heavy implementations in praisonai/bots/)
• Bot protocols: ✅ CORE layer (lightweight interfaces in praisonaiagents/bots/protocols.py)
• Plugin system: ✅ Exists in CORE layer with runtime extension points
• Channel plugins: Would be PLUGINS or WRAPPER extensions

📋 DECISION: Keep Status Quo + Enhance Registry

Recommendation: DO NOT build a separate channel plugin SDK

Reasoning:

1. 🎯 PraisonAI's Philosophy Conflicts with OpenClaw Model:

   • PraisonAI: Agent-centric, protocol-driven core, heavy implementations in wrapper
   • OpenClaw: Channel-plugin centric with installable marketplace model
   • Adding channel plugin SDK would violate "protocol-driven core" principle

2. ✅ Current Architecture is Already Extensible:

   # Current extensibility (runtime registration)
   from praisonai.bots._registry import register_platform
   
   class LineBot:
       async def start(self): ...
       async def stop(self): ...
   
   register_platform("line", LineBot)
   bot = Bot("line", agent=agent, token="LINE_TOKEN")

3. 🚫 Channel Plugin SDK Would Violate Core Principles:

   • Performance: Channel plugins would require heavy imports in core SDK
   • Protocol-driven: Would bloat core with implementation details
   • Minimal API: Would add complexity to Agent initialization

4. 📦 Existing Plugin System Serves Different Purpose:

   • Current plugins: Framework lifecycle extensions (logging, metrics, hooks)
   • Channel plugins would be: Infrastructure adapters
   • These are fundamentally different concerns

🎯 Recommended Pattern for New Channels

For Community Contributors:

# 1. Implement BotProtocol in external package
# External package: praisonai-line-bot
class LineBot:
    async def start(self): ...
    async def stop(self): ...
    async def send_message(self, channel_id, content): ...
    # ... implement full BotProtocol

# 2. Users install and register
pip install praisonai-line-bot

# 3. Register at runtime
from praisonai.bots import Bot
from praisonai.bots._registry import register_platform
from praisonai_line_bot import LineBot

register_platform("line", LineBot)
bot = Bot("line", agent=agent)  # Works seamlessly

For Core Team:

• Add new platforms directly to praisonai/bots/ (like current Telegram/Discord)
• Follow existing pattern: inherit from common base, implement BotProtocol
• Update _registry.py builtin platforms

📖 Documentation Updates Needed

Create contributor guide:

# Adding New Messaging Platforms

## Option 1: External Package (Recommended for Community)
1. Create pip package implementing BotProtocol
2. Use register_platform() for runtime registration
3. Distribute via PyPI

## Option 2: Core Integration (Core Team Only)  
1. Add to src/praisonai/praisonai/bots/your_platform.py
2. Update _registry.py BUILTIN_PLATFORMS
3. Follow existing TelegramBot/DiscordBot patterns

✨ Enhancements to Current System

Minor improvements without architecture changes:

1. Better Discovery:

   from praisonai.bots import list_platforms
   print(list_platforms())  # ['telegram', 'discord', 'slack', 'custom_platform']

2. Enhanced Registry:

   # Already exists, just needs documentation
   register_platform("mychat", MyChatBot)

3. Validation:

   # Add runtime BotProtocol validation in Bot.__init__
   if not isinstance(adapter, BotProtocol):
       raise TypeError(f"{adapter} must implement BotProtocol")

🎯 Final Recommendation

❌ Do not implement OpenClaw-style channel plugin SDK

✅ Document and enhance current extensibility model:

1. Keep agent-centric, protocol-driven architecture
2. Enhance documentation for community channel contributions
3. Improve platform discovery and validation
4. Maintain clear separation: Core protocols, Wrapper implementations

The current architecture already provides the extensibility OpenClaw offers, just with different distribution patterns that align with PraisonAI's core principles.

---