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:
PluginContextPluginEventBusSynapsePluginChannelModelProvider- 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:
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:
Possible architecture:
Possible plugin flow:
Potential additions to the plugin API:
Example service registration:
Example usage:
Alternatives
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:
PluginContextPluginEventBusSynapsePluginChannelModelProviderThis issue mainly proposes evolving the API into a more generic integration ecosystem over time.