# Connecting Signal with AI Agents: My Open-Source Contribution to Switch
!Image description
I have been spending time contributing to Switch, an open-source project that connects AI agents with messaging platforms.
For my next contribution, I worked on something a little different: adding Signal support to Switch.
The idea is simple. What if you could communicate with your AI agents through Signal, just like you communicate with people?
This turned into a really interesting engineering task. I had to understand how Signal works, how Switch handles messaging platforms, and how to make the integration reliable when the application runs across multiple server instances.
Here is how I approached it.
Why Signal?
Most people already use messaging applications to communicate with their teams, friends, or colleagues.
Signal is especially interesting because of its focus on privacy and end-to-end encrypted messaging.
I noticed that Switch did not have a Signal integration, so I started looking into how one could be added.
I found this issue:
Add Signal as a messaging platform – Issue #792
One important detail made this integration different from other messaging platforms: Signal does not provide an official bot API.
Instead, the integration needed to use signal-cli, an unofficial command-line client that provides a way to interact with Signal.
That became the starting point for my implementation.
Understanding how it works
Before writing the adapter, I needed to understand the communication flow.
The basic architecture looks like this:
1. A user runs and registers a Signal account through signal-cli.
2. signal-cli runs as an HTTP daemon.
3. Switch connects to that daemon.
4. Incoming Signal messages are received through Server-Sent Events (SSE).
5. Switch forwards messages to the appropriate AI agent.
6. The agent's response is sent back through Signal.
For communication with the daemon, the implementation uses JSON-RPC 2.0.
This approach allows Switch to communicate with Signal without pretending that Signal has an official bot API.
What I implemented
I added a Signal messaging adapter that supports several useful messaging features.
1. Direct messages
Users can communicate with their AI agents through Signal direct messages.
2. Group conversations
Signal groups can be mapped to Switch rooms, allowing agents to participate in group conversations.
3. Quote replies
Signal does not work like messaging platforms that have traditional threaded conversations.
To preserve conversation context, the adapter uses quote replies. This helps connect an agent's response to the original message.
4. Note to Self
The integration also supports Signal's Note to Self feature.
5. Activity indicators
I worked on routing activity indicators through Signal reactions, including:
- 👀 When an agent is working.
- ⏳ When work is queued.
The adapter also supports temporary typing notifications.
6. Credential verification
Before saving a bridge configuration, the adapter checks whether the Signal daemon is reachable and can list its groups.
This helps catch connection problems earlier.
The most interesting challenge: Multi-instance deployments
One of the most valuable parts of this contribution was the feedback I received during review.
Initially, I was focused on getting the Signal adapter working correctly on my local machine.
However, Switch needs to support multiple instances of switch-core running at the same time.
This is important for larger deployments where different server instances can take responsibility for a messaging connection.
A maintainer pointed out two problems with my initial implementation:
- The quote cache was stored in local process memory. When another server instance took over, that instance would not have the previous cache.
- The documentation used 127.0.0.1 for the Signal daemon. That would not work when the active Switch instance and the daemon were running in different containers or services.
This feedback helped me understand an important difference between code that works locally and code that works in a distributed deployment.
I updated the implementation to address these concerns.
For the quote cache:
I replaced the unbounded dictionary with a capped OrderedDict LRU cache containing up to 1,000 items.
I also updated quote-reply handling to pass the original timestamp directly from the turn root target. This allows replies to work after a bridge moves to another instance without depending on a locally cached author or message entry.
For daemon connectivity:
I updated the documentation to recommend a shared internal daemon endpoint instead of relying on localhost.
For example:
http://signal-cli:8080
This makes the setup more appropriate for deployments where multiple server instances need to reach the same daemon.
I also added tests for these cases.
A few additional fixes
While working through the review feedback, I also improved some smaller parts of the adapter.
These included:
- Better detection of messages sent by the connected Signal account, so ordinary messages starting with text like [urgent] are not accidentally ignored.
- Proper handling of failed user additions.
- Whitespace cleanup when validating the daemon endpoint.
- Better connection checks before saving credentials.
These changes may look small individually, but they make the integration more dependable.
Testing the implementation
I wanted to make sure that the adapter worked beyond the happy path.
The submitted PR reports:
50 passed in 1.17s
The tests cover adapter behavior and bridge registry behavior.
Some of the important scenarios include:
- Signal message handling.
- Quote replies after switching to a fresh server instance.
- LRU cache eviction.
- Credential verification.
- Activity indicators.
- Messages that begin with square brackets.
- Bridge registration behavior.
I also tested the integration with a local signal-cli 0.14.9 daemon linked to a Signal device.
During the smoke test, I sent an outbound message to Note to Self, checked the delivery receipt, and verified incoming events through the SSE stream.
The submitted validation also reports:
- Ruff checks passed.
- Ruff formatting passed.
- Strict mypy checks passed with zero errors.
My contribution
Here are the details of my implementation:
Project: Switch
Platform: Signal
Integration: signal-cli HTTP daemon
Communication: JSON-RPC 2.0 and Server-Sent Events
Pull Request: #1041 – Add Signal messaging platform adapter
Original Issue: #792 – Add Signal as a messaging platform
The submitted PR contains:
- 9 changed files.
- 1,718 additions.
- Signal adapter implementation.
- Automated tests.
- Signal setup documentation.
- Improvements addressing multi-instance deployment concerns.
The PR is currently open and has not yet been merged.
What I learned from this contribution
This was a good reminder that implementing a feature is only one part of contributing to an open-source project.
I learned more about:
- Connecting applications through JSON-RPC and SSE.
- Working with messaging platform adapters.
- Handling quote-based conversation context.
- Understanding multi-instance application deployments.
- Writing tests for edge cases.
- Taking maintainer feedback and turning it into code improvements.
The biggest lesson for me was that a feature working on one machine does not automatically mean it will work in a real deployment.
Understanding how the rest of the system behaves is just as important as writing the feature itself.
Final thoughts
I enjoyed working on this integration because it pushed me beyond simply implementing an API connection.
It gave me a chance to understand a different messaging architecture, work through real review feedback, and improve the implementation for a more realistic deployment environment.
Thanks to the Switch maintainers for taking the time to explain the architectural concerns and provide feedback.
I am continuing to contribute to open-source projects, learn from code reviews, and build things that solve practical problems.
For me, that is one of the best parts of open source: you write code, get feedback, learn something new, and make the project better together.
Useful links
- Switch Repository
- Signal Adapter PR #1041
- Original Issue #792
- signal-cli
3 reactions
Mentions
# Connecting Signal with AI Agents: My Open-Source Contribution to Switch !Image description I have been spending time contributing to Switch, an open-source project that connects AI agents with messaging platforms. For my next contribution, I worked on something a little different: adding Signal support to Switch. The idea is simple. What if you could communicate with your AI agents through Signal, just like you communicate with people? This turned into a really interesting engineering task. I had to understand how Signal works, how Switch handles messaging platforms, and how to make the integration reliable when the application runs across multiple server instances. Here is how I approached it. Why Signal? Most people already use messaging applications to communicate with their teams, friends, or colleagues. Signal is especially interesting because of its focus on privacy and end-to-end encrypted messaging. I noticed that Switch did not have a Signal integration, so I started looking into how one could be added. I found this issue: Add Signal as a messaging platform – Issue #792 One important detail made this integration different from other messaging platforms: Signal does not provide an official bot API. Instead, the integration needed to use signal-cli, an unofficial command-line client that provides a way to interact with Signal. That became the starting point for my implementation. Understanding how it works Before writing the adapter, I needed to understand the communication flow. The basic architecture looks like this: 1. A user runs and registers a Signal account through signal-cli. 2. signal-cli runs as an HTTP daemon. 3. Switch connects to that daemon. 4. Incoming Signal messages are received through Server-Sent Events (SSE). 5. Switch forwards messages to the appropriate AI agent. 6. The agent's response is sent back through Signal. For communication with the daemon, the implementation uses JSON-RPC 2.0. This approach allows Switch to communicate with Signal without pretending that Signal has an official bot API. What I implemented I added a Signal messaging adapter that supports several useful messaging features. 1. Direct messages Users can communicate with their AI agents through Signal direct messages. 2. Group conversations Signal groups can be mapped to Switch rooms, allowing agents to participate in group conversations. 3. Quote replies Signal does not work like messaging platforms that have traditional threaded conversations. To preserve conversation context, the adapter uses quote replies. This helps connect an agent's response to the original message. 4. Note to Self The integration also supports Signal's Note to Self feature. 5. Activity indicators I worked on routing activity indicators through Signal reactions, including: - 👀 When an agent is working. - ⏳ When work is queued. The adapter also supports temporary typing notifications. 6. Credential verification Before saving a bridge configuration, the adapter checks whether the Signal daemon is reachable and can list its groups. This helps catch connection problems earlier. The most interesting challenge: Multi-instance deployments One of the most valuable parts of this contribution was the feedback I received during review. Initially, I was focused on getting the Signal adapter working correctly on my local machine. However, Switch needs to support multiple instances of switch-core running at the same time. This is important for larger deployments where different server instances can take responsibility for a messaging connection. A maintainer pointed out two problems with my initial implementation: - The quote cache was stored in local process memory. When another server instance took over, that instance would not have the previous cache. - The documentation used 127.0.0.1 for the Signal daemon. That would not work when the active Switch instance and the daemon were running in different containers or services. This feedback helped me understand an important difference between code that works locally and code that works in a distributed deployment. I updated the implementation to address these concerns. For the quote cache: I replaced the unbounded dictionary with a capped OrderedDict LRU cache containing up to 1,000 items. I also updated quote-reply handling to pass the original timestamp directly from the turn root target. This allows replies to work after a bridge moves to another instance without depending on a locally cached author or message entry. For daemon connectivity: I updated the documentation to recommend a shared internal daemon endpoint instead of relying on localhost. For example: http://signal-cli:8080 This makes the setup more appropriate for deployments where multiple server instances need to reach the same daemon. I also added tests for these cases. A few additional fixes While working through the review feedback, I also improved some smaller parts of the adapter. These included: - Better detection of messages sent by the connected Signal account, so ordinary messages starting with text like [urgent] are not accidentally ignored. - Proper handling of failed user additions. - Whitespace cleanup when validating the daemon endpoint. - Better connection checks before saving credentials. These changes may look small individually, but they make the integration more dependable. Testing the implementation I wanted to make sure that the adapter worked beyond the happy path. The submitted PR reports: 50 passed in 1.17s The tests cover adapter behavior and bridge registry behavior. Some of the important scenarios include: - Signal message handling. - Quote replies after switching to a fresh server instance. - LRU cache eviction. - Credential verification. - Activity indicators. - Messages that begin with square brackets. - Bridge registration behavior. I also tested the integration with a local signal-cli 0.14.9 daemon linked to a Signal device. During the smoke test, I sent an outbound message to Note to Self, checked the delivery receipt, and verified incoming events through the SSE stream. The submitted validation also reports: - Ruff checks passed. - Ruff formatting passed. - Strict mypy checks passed with zero errors. My contribution Here are the details of my implementation: Project: Switch Platform: Signal Integration: signal-cli HTTP daemon Communication: JSON-RPC 2.0 and Server-Sent Events Pull Request: #1041 – Add Signal messaging platform adapter Original Issue: #792 – Add Signal as a messaging platform The submitted PR contains: - 9 changed files. - 1,718 additions. - Signal adapter implementation. - Automated tests. - Signal setup documentation. - Improvements addressing multi-instance deployment concerns. The PR is currently open and has not yet been merged. What I learned from this contribution This was a good reminder that implementing a feature is only one part of contributing to an open-source project. I learned more about: - Connecting applications through JSON-RPC and SSE. - Working with messaging platform adapters. - Handling quote-based conversation context. - Understanding multi-instance application deployments. - Writing tests for edge cases. - Taking maintainer feedback and turning it into code improvements. The biggest lesson for me was that a feature working on one machine does not automatically mean it will work in a real deployment. Understanding how the rest of the system behaves is just as important as writing the feature itself. Final thoughts I enjoyed working on this integration because it pushed me beyond simply implementing an API connection. It gave me a chance to understand a different messaging architecture, work through real review feedback, and improve the implementation for a more realistic deployment environment. Thanks to the Switch maintainers for taking the time to explain the architectural concerns and provide feedback. I am continuing to contribute to open-source projects, learn from code reviews, and build things that solve practical problems. For me, that is one of the best parts of open source: you write code, get feedback, learn something new, and make the project better together. Useful links - Switch Repository - Signal Adapter PR #1041 - Original Issue #792 - signal-cli