Integration Plugin System with Calendar/Mail/Service Providers #37

New issue

Open

opened 2026-05-19 00:50:29 +02:00 by FTMahringer · 0 comments

FTMahringer commented

2026-05-19 00:50:29 +02:00

(Migrated from github.com)

Problem / Motivation

Synapse currently has a strong plugin foundation with channel and model provider support, but future integrations (Infomaniak, Nextcloud, Google Calendar, Mail systems, GitHub, etc.) will require a more generic integration/provider architecture.

The goal is to allow Synapse to act as an orchestration layer between external services:

Mail systems (SMTP/IMAP)
Calendar systems (CalDAV/iCal)
Messaging systems
Git providers
File providers
Future automation systems

Example use-case:

A mail plugin receives a message sent to contact@domain.com.
Synapse checks connected calendar providers for current availability/status.
Based on calendar events (vacation, busy, out-of-office, exams, etc.), Synapse dynamically generates an automatic response.

This would allow intelligent autoresponders and automation flows driven by plugins and external integrations.

Proposed Solution

Expand the plugin API toward a provider/service-based architecture.

Instead of Synapse core knowing specific services directly, plugins should register generic provider interfaces.

Possible provider interfaces:

MailProvider
CalendarProvider
FileProvider
SecretProvider
WebhookProvider
ToolProvider
AuthProvider

Possible architecture:

Synapse Core
 ├── Plugin Runtime
 ├── Event Bus
 ├── Service Registry
 └── Scheduler

Plugins
 ├── Infomaniak Plugin
 ├── Nextcloud Plugin
 ├── GitHub Plugin
 ├── Telegram Plugin
 └── Calendar Plugin

Possible plugin flow:

MailReceivedEvent
  → CalendarProvider checks availability
  → Rule Engine selects template
  → Template Engine generates response
  → MailProvider sends response

Potential additions to the plugin API:

Typed event system
Plugin service registry
Scheduler/task API
Secret management abstraction
Provider discovery system
Rule/automation hooks

Example service registration:

context.services().register(CalendarProvider.class, this);

Example usage:

CalendarProvider provider = context.services().get(CalendarProvider.class);

Alternatives

Keep all integrations directly inside Synapse core
Only support channel/model plugins
Hardcode integrations instead of provider abstractions

These approaches reduce flexibility and make future integrations harder to maintain.

Priority

Medium / High

This is likely important for future automation/orchestration features and for positioning Synapse as more than only an LLM/chat platform.

Additional Notes

The current plugin API foundation is already strong:

PluginContext
PluginEventBus
SynapsePlugin
Channel
ModelProvider
Bytecode sandbox scanning

This issue mainly proposes evolving the API into a more generic integration ecosystem over time.

## Problem / Motivation Synapse currently has a strong plugin foundation with channel and model provider support, but future integrations (Infomaniak, Nextcloud, Google Calendar, Mail systems, GitHub, etc.) will require a more generic integration/provider architecture. The goal is to allow Synapse to act as an orchestration layer between external services: - Mail systems (SMTP/IMAP) - Calendar systems (CalDAV/iCal) - Messaging systems - Git providers - File providers - Future automation systems Example use-case: A mail plugin receives a message sent to `contact@domain.com`. Synapse checks connected calendar providers for current availability/status. Based on calendar events (vacation, busy, out-of-office, exams, etc.), Synapse dynamically generates an automatic response. This would allow intelligent autoresponders and automation flows driven by plugins and external integrations. --- ## Proposed Solution Expand the plugin API toward a provider/service-based architecture. Instead of Synapse core knowing specific services directly, plugins should register generic provider interfaces. Possible provider interfaces: ```java MailProvider CalendarProvider FileProvider SecretProvider WebhookProvider ToolProvider AuthProvider ``` Possible architecture: ```text Synapse Core ├── Plugin Runtime ├── Event Bus ├── Service Registry └── Scheduler Plugins ├── Infomaniak Plugin ├── Nextcloud Plugin ├── GitHub Plugin ├── Telegram Plugin └── Calendar Plugin ``` Possible plugin flow: ```text MailReceivedEvent → CalendarProvider checks availability → Rule Engine selects template → Template Engine generates response → MailProvider sends response ``` Potential additions to the plugin API: - Typed event system - Plugin service registry - Scheduler/task API - Secret management abstraction - Provider discovery system - Rule/automation hooks Example service registration: ```java context.services().register(CalendarProvider.class, this); ``` Example usage: ```java CalendarProvider provider = context.services().get(CalendarProvider.class); ``` --- ## Alternatives - Keep all integrations directly inside Synapse core - Only support channel/model plugins - Hardcode integrations instead of provider abstractions These approaches reduce flexibility and make future integrations harder to maintain. --- ## Priority Medium / High This is likely important for future automation/orchestration features and for positioning Synapse as more than only an LLM/chat platform. --- ## Additional Notes The current plugin API foundation is already strong: - `PluginContext` - `PluginEventBus` - `SynapsePlugin` - `Channel` - `ModelProvider` - Bytecode sandbox scanning This issue mainly proposes evolving the API into a more generic integration ecosystem over time.