Refactor communication channels into a unified adapter framework

[blackhammer116]

Description

This PR refactors the communication channel layer to provide a common adapter interface across all supported messaging backends (IRC, Telegram, Slack, and Mattermost). The goal is to reduce duplicated logic, simplify channel integration, and make adding new communication backends significantly easier.

Main changes

Introduce BaseChannel

• Add a common BaseChannel abstract class that encapsulates shared functionality:

  • message buffering
  • thread lifecycle management
  • authentication handling
  • common helper methods

• Channel-specific implementations now only need to implement their transport logic (_run_loop) and message sending.

Add channel registry

• Introduce channels_registry.py as a central entry point for channel initialization.
• Channel selection is now dynamic rather than hardcoded in MeTTa.
• Default configuration values are centralized in one place.

Refactor existing adapters

Refactor the following adapters to inherit from BaseChannel:

• IRC
• Telegram
• Slack
• Mattermost

This removes a significant amount of duplicated code while preserving existing behavior.

Simplify MeTTa integration

src/channels.metta has been simplified to interact with a single registry instead of containing channel-specific branching logic.

Initialization now becomes:

• configure channel parameters
• invoke channels_registry.start(...)

Sending and receiving messages are similarly routed through the registry, reducing the MeTTa code considerably.

Library updates

• Export the new channel framework through lib_omegaclaw.metta.
• Include the new BaseChannel and channels_registry modules.

Benefits

• Removes duplicated authentication and lifecycle logic across adapters.
• Makes channel implementations substantially smaller and easier to maintain.
• Provides a consistent interface for future communication backends.
• Centralizes configuration and startup logic.
• Simplifies the MeTTa layer by removing channel-specific dispatch.

Notes

The refactor is intended to preserve existing behavior while restructuring the implementation. Aside from the unified initialization path and centralized configuration, channel functionality should remain unchanged.

Checklist

• The code generated by LLM is reviewed by the PR creator
• Self-review completed
• Test scenarios above are passed with the version of the code from PR

[vsbogd]

1. This PR contains two different types of changes: the refactoring of the existing channels and introducing registry of channels. I would split these two parts on two different changes.

2. I would not try to abstract the channel implementation into the BaseChannel class at least on the API level. The _run_loop method is an abstraction which doesn't cover the all possible implementations. For example one could have a communication channel without _run_loop at all for example mock.py which is present in OmegaClaw-Core doesn't use such loop at all.

The BaseChannel can be a good abstraction some of the channels, but the high-level API we have is sendMessage/removeMessage and BaseChannel doesn't provide the way to implement this abstraction.

3. The registry of the channels which is introduced requires modification each time when new integration is added which contradicts to our goal to have ability adding the new channel integration without modifying the core. Channel configuration should not be visible in the code outside of the channel implementation by the same reason.

[blackhammer116]

1. This PR contains two different types of changes: the refactoring of the existing channels and introducing registry of channels. I would split these two parts on two different changes.
2. I would not try to abstract the channel implementation into the BaseChannel class at least on the API level. The _run_loop method is an abstraction which doesn't cover the all possible implementations. For example one could have a communication channel without _run_loop at all for example mock.py which is present in OmegaClaw-Core doesn't use such loop at all.

The BaseChannel can be a good abstraction some of the channels, but the high-level API we have is sendMessage/removeMessage and BaseChannel doesn't provide the way to implement this abstraction.

3. The registry of the channels which is introduced requires modification each time when new integration is added which contradicts to our goal to have ability adding the new channel integration without modifying the core. Channel configuration should not be visible in the code outside of the channel implementation by the same reason.

Hey @vsbogd, this was just a draft PR for discussion purposes I don't have any intention of merging the code to core at this stage, that being said mock.py would be accommodated easily this is just to show that initialization of comm channels can be abstracted and they can take a single unified architecture while having their own different flavors.

I'm assuming by removeMessage you meant receiveMessage (if not, then I don't know what you mean, can you clarify?) the send and recieve are both implemented, which would be backward compatible to the core using send_message and getLastMessage functions, which are implemented in each comm channel's .py files.

Since the overall plan is to move the channels dir out of core, making it a separate installable package just like import-kb, the only entry point required will be the channels.metta for initialization, and if more channels are required, we would just tag the package as latest and we'll just modify the package instead of modifying the core code.

Again this PR is just to show you the idea of how we can structure it, this does not represent the final implementation.

[vsbogd]

Closing this as it communication channel registry part is part of #222