refactor: improve XMPP client/bridge architecture separation

- Move protocol normalization methods to XMPP client (ExtractChannelID, ExtractUserInfo, ExtractMessageBody)
- Replace message channel aggregation with direct handler delegation pattern
- XMPP client now focuses purely on protocol concerns (connection, deduplication, normalization)
- XMPP bridge handles business logic (BridgeMessage creation, routing)
- Add SourceRemoteID field to BridgeMessage for better message tracking
- Remove unused message channel infrastructure in favor of mux.MessageHandlerFunc pattern

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Felipe M 2025-08-06 12:31:28 +02:00
parent 8e9d87b176
commit 11a32afc53
No known key found for this signature in database
GPG key ID: 52E5D65FCF99808A
3 changed files with 127 additions and 125 deletions

View file

@ -15,10 +15,11 @@ const (
// BridgeMessage represents a message that can be passed between any bridge types
type BridgeMessage struct {
// Source information
SourceBridge string // "xmpp", "mattermost", "slack", etc.
SourceChannelID string // Channel ID in source system
SourceUserID string // User ID in source system (JID, user ID, etc.)
SourceUserName string // Display name in source system
SourceBridge string // "xmpp", "mattermost", "slack", etc.
SourceChannelID string // Channel ID in source system
SourceUserID string // User ID in source system (JID, user ID, etc.)
SourceUserName string // Display name in source system
SourceRemoteID string // Remote ID of the bridge instance that created this message
// Message content (standardized on Markdown)
Content string // Markdown formatted message content