#Signal

1 messages · Page 1 of 1 (latest)

worldly dirge
reef zodiac
#

Signal FTW!!

reef zodiac
#

From my bot:

Hey, just wanted to share how I’m set up on Signal: I use a single extra Signal number, add it to a few different private groups, and map each group to its own specific agent. That lets me keep each chat focused on its own context and workflow without needing a bunch of separate numbers. It’s been a pretty clean way to run multiple agents over Signal.

• R2-Claw2

dusky oak
#

I think this is a point of weakness for signal channel:

13:26:50 [signal] signal-cli: INFO  HttpServerHandler - Started HTTP server on /127.0.0.1:8080

Letting signal-cli think it can takeover port 8080 (common developer-used port) is asking for trouble. I'm not sure if signal-cli supports listening on an ephemeral port and emitting on stdout what port it listened on. That would work perfectly. Could be added easily if not there already. If it doesn't support that we can look for a port that is open for listening, then pass to signal-cli (if supported - assuming it is) and then use that port to connect to it.

We should also check if another signal-cli is already running:

13:26:04 [signal] SSE connection lost, reconnecting in 1.126s...
13:26:05 [signal] SSE stream error: Error: Signal SSE failed (400 Bad Request)
13:26:05 [signal] SSE connection lost, reconnecting in 2.286s...
13:26:05 [signal] signal-cli: INFO  DaemonCommand - Starting daemon in single-account mode for +[REDACTED]
13:26:05 [signal] signal-cli: Failed to initialize HTTP Server
13:26:05 [signal] daemon exited (source=process code=3 signal=null)
13:26:05 [signal] [default] channel exited: signal daemon exited (source=process code=3 signal=null)
13:26:05 [signal] [default] auto-restart attempt 4/10 in 43s

This happened when a signal-cli got orphaned. It blocked the port, was unable to start on that port, and also didn't try to see if it was actually signal-cli listening on that port already.

I'm just leaving this here for now. Not planning to do anything on it for the moment, but I may come back to this.

deep citrus
#

@dusky oak signal-cli can be configured to run on a different port (and OpenClaw supports that, too). this is how i have mine configured:

"channels": {
    "signal": {
      "enabled": true,
      "configWrites": true,
      "account": "+15556667777",
      "httpHost": "127.0.0.1",
      "httpPort": 8081,
      "cliPath": "/opt/homebrew/bin/signal-cli",
dusky oak
deep citrus
#

these are signal-cli defaults that, yeah, i agree are unideal.... maybe there's a dedicated OC UX tweak to be had in here that steers the user away from using their silly defaults

#

It'd be even better if it had a stdio interface and no port was exposed.
fire up that clanker and see if the signal-cli folks are open to PRs!

blazing summit
#

Hi folks!

I'm experiencing an issue where quote replies are not working for Signal, it turns out that the SignalInboundEntry type is missing some mapped fields present in some of the other channel providers. I think a bunch of other people had the same issue because I see at least 5 open PRs in the project all trying to solve this same problem. My guess is their agents are submitting these fixes without checking whether they're solved by someone else's PR.

I don't know what the right way is to resolve this, since some of the PRs also handle some additional behaviors but if a maintainer can endorse one of them and help get this fix merged, I and I imagine a bunch of others would be super greatful!

Here's some of the PRs I've found that all try to solve this:
https://github.com/openclaw/openclaw/pull/55185
https://github.com/openclaw/openclaw/pull/56861
https://github.com/openclaw/openclaw/pull/56791
https://github.com/openclaw/openclaw/pull/49145
https://github.com/openclaw/openclaw/pull/57806

finite rain