[Gap] Channels ship in-tree + register_platform(), not installable plugin packs — vs OpenClaw channel SDK

[Dhivya-Bharathy]

[Gap] Channels ship in-tree + register_platform(), not installable plugin packs — vs OpenClaw channel SDK

Executive summary

Field	Content
OpenClaw reference	Channel plugin SDK, SDK overview, community/distribution — installable channel plugins as a product concept.
PraisonAI reality	New messengers are Python modules under praisonai/bots/ registered in _BUILTIN_PLATFORMS or via register_platform() at runtime — no packaged plugin manifest, versioned channel package format, or marketplace flow comparable to OpenClaw’s channel-plugin story in this repo.
Gap type	Extensibility model — contributor path is edit core tree or imperative register_platform, not “drop in channel plugin package.”
Severity	Platform / parity. Affects: long-tail enterprise messengers, community-owned channels.

---

1. Built-in platforms — static dictionary + lazy import

File: src/praisonai/praisonai/bots/_registry.py

_BUILTIN_PLATFORMS: Dict[str, tuple] = {
    "telegram": ("praisonai.bots.telegram", "TelegramBot"),
    "discord": ("praisonai.bots.discord", "DiscordBot"),
    "slack": ("praisonai.bots.slack", "SlackBot"),
    "whatsapp": ("praisonai.bots.whatsapp", "WhatsAppBot"),
    "email": ("praisonai.bots.email", "EmailBot"),
    "agentmail": ("praisonai.bots.agentmail", "AgentMailBot"),
}

Resolution loads the module by string path:

    if key in _BUILTIN_PLATFORMS:
        ref = _BUILTIN_PLATFORMS[key]
        if isinstance(ref, tuple):
            module_path, class_name = ref
            import importlib
            mod = importlib.import_module(module_path)
            return getattr(mod, class_name)

Takeaway: Adding a new first-class channel today implies shipping a new module under praisonai.bots.* and editing _BUILTIN_PLATFORMS (or relying on register_platform at process start — see below).

---

2. Runtime registration API (no package format)

File: src/praisonai/praisonai/bots/_registry.py

def register_platform(name: str, adapter_class: Type) -> None:
    """Register a custom platform adapter.
    ...
    """
    _custom_platforms[name.lower()] = adapter_class

Takeaway: This is a process-local registry hook — powerful, but not equivalent to OpenClaw’s channel plugin SDK (manifest, entrypoints, install UX, versioning, isolation). There is no plugins/ channel bundle layout in-tree for third parties.

---

3. Public package surface — fixed lazy exports

File: src/praisonai/praisonai/bots/__init__.py

__getattr__ hard-codes imports for TelegramBot, DiscordBot, SlackBot, WhatsAppBot, EmailBot, AgentMailBot, Bot, BotOS, approval helpers (__init__.py:25–65).

__all__ lists the same concrete names (__init__.py:68–73).

Takeaway: The documented ergonomic API is tied to known bots — not “load_plugin('acme-slack-fork')”.

---

4. Directory inventory (in-tree channels)

Under src/praisonai/praisonai/bots/ (authoring snapshot):

• Adapters: telegram.py, discord.py, slack.py, whatsapp.py, email.py, agentmail.py
• Core: bot.py, botos.py, _registry.py, shared _*.py helpers

No subdirectory such as plugins/, third_party_channels/, or dynamic wheel-loading samples in this trace.

---

5. Architecture (Mermaid)

OpenClaw (conceptual — channel plugins)

flowchart LR
  H[Channel hub / SDK]
  P1[Plugin pkg A]
  P2[Plugin pkg B]
  H --> P1
  H --> P2

Loading

PraisonAI (this repo)

flowchart TB
  REG[_BUILTIN_PLATFORMS dict]
  MOD[praisonai.bots.* modules]
  CUST[register_platform at runtime]
  REG --> MOD
  CUST --> REG

Loading

Gap: No third box for installable channel plugin packages with stable ABI documented like OpenClaw.

---

6. Comparison matrix

Dimension	OpenClaw (documented)	PraisonAI (this repo)
Add channel	Plugin SDK / bundles	New module in bots/ + registry edit or register_platform
Discovery	Community / registry story	Code + docs
Versioning	Plugin versioning	Praison release cadence
Isolation	Plugin boundary	Shared process / imports

---

7. MCP / webhooks (related, not duplicate)

Praison can integrate external systems via MCP and webhooks elsewhere in the stack — this issue is only about in-process channel adapter parity with OpenClaw’s channel plugin model. MCP is a different integration style.

---

8. Suggested engineering directions

1. Wontfix: Position MCP + webhooks as the extension path; close with rationale.
2. RFC: Define praisonai-channel-*.whl manifest (name, entrypoint class, config schema) + praisonai bots plugin install.
3. Minimal spike: Load one example plugin from entry_points (importlib.metadata) behind feature flag.

---

9. Acceptance criteria

• Decision: plugin SDK epic | MCP-only | hybrid.
• If SDK: hello-world plugin repo + tests + docs.
• If wontfix: evaluator-facing paragraph on extension model.

---

10. Out of scope

• Rewriting Telegram/Slack adapters.
• Marketplace payments / legal review — until technical load path exists.

---

Appendix — files cited

Path	Role
src/praisonai/praisonai/bots/_registry.py	Built-ins + register_platform + resolve_adapter
src/praisonai/praisonai/bots/__init__.py	Lazy exports, __all__
src/praisonai/praisonai/bots/*.py	Concrete channel implementations

---

Evidence from PraisonAI src/praisonai/; re-verify after refactors.

[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.

---