Decision (2026-10-18, Frank): move machine traffic to Telegram, not a second Signal number
Alter this issue to switch this functionality over to Telegram (assuming Telegram allows number-less signup)
The assumption is half right, and right where it matters:
A Telegram bot has no phone number at all. It is created by messaging @BotFather and authenticates with a token. That kills the whole "where does the machine get a number" problem — no SIM, no rented DID, no SMS/voice confirmation.
A Telegram user account still needs a number. Telegram's official no-SIM signup works by registering against a blockchain anonymous number bought on Fragment (paid, and it takes an existing account to buy one) — telegram.org/blog/ultimate-privacy-topics-2-0. So "free numberless signup" does not exist for a user identity. We do not need one.
Signal stays out of machine traffic; the existing signal-cli account (your mobile) is left alone.
Why the current path is broken (unchanged root cause)
scripts/signal-relay.py hardcodes both sides of every message to the same identity:
Signal delivers a message sent from a number to itself as a note to self, and notes to self raise no notification. Verified on the host today: signal-cli 0.14.7, listAccounts returns exactly one account, +12062476336, with Messages have been last received 46 days ago — a send-only identity, exactly as the symptom predicts.
For completeness of the Signal option set: signal-cli 0.14.7's register is phone-number-only (Register a phone number with SMS or voice), Signal's numberless Signal Login is a paid, one-time registration still in Android beta with no signal-cli path, and Signal usernames only hide a number from people you message — registration still needs one. So Telegram is strictly the cheaper door: the machine identity costs nothing and needs no hardware.
Verified precondition
The Bot API is reachable from Dankclaw with no proxy — a deliberately bogus token, so this proves DNS + TLS + the API path, not auth:
You create one bot in Telegram: message @BotFather → /newbot → pick a name and a username ending in bot. You get a token shaped 123456789:AA....
The token never enters the repo or the command line. It goes in /home/dank/.config/secrets/telegram-relay.env (mode 600) as TELEGRAM_BOT_TOKEN=..., pulled in by EnvironmentFile. The repo carries the path and the non-secret tunables only, same rule as every other secret here (and the same rule a HF token broke on 2026-09-16: a token in curl -H argv is world-readable through /proc/<pid>/cmdline).
The bot cannot open a conversation — Telegram requires the human to message the bot first. So: send the new bot one message (and/or add it to a private group and talk there), then the relay resolves your numeric chat_id from getUpdates and posts to it. One-time interactive step, which is why this issue is yours.
scripts/signal-relay.py becomes scripts/telegram-relay.py — same listener contract (bind 192.168.0.143:18093, the one address a bridge container can actually reach; iptables still admits only the podman bridge subnet), same format_group message text, same 15-minute dedupe, same MAX_INSTANCES cap. POST https://api.telegram.org/bot$TOKEN/sendMessage with chat_id + text replaces the signal-cli send; a missing token file logs by name instead of dying silently.
Multiple recipients are a list, TELEGRAM_CHAT_IDS, so a second human or a future agent target is one line — the per-service attribution problem this issue raised disappears: the machine identity is one bot, and every message names its alert.
Cost of the swap, stated plainly
Telegram is cloud-stored (MTProto client-server); Signal is end-to-end sealed-sender. Alert payloads carry hostnames, service names and firing rules — no credentials — so this is an acceptable disclosure, but it is a disclosure and it is recorded here as one.
The bot token is a bearer credential: anyone holding it can send as the fleet bot. Mode 600, out of argv, out of git, out of logs.
Bot send limits (~1 msg/s per chat, ~30/s global) are far below the 15-minute dedupe window, so no risk of a Telegram 429 storm from a misconfigured rule.
Rollback is a file move: the Signal unit and signal-relay.py are retired to ~/.AGENTTRASH/, not deleted, per the deletion policy.
Open questions (one decision each)
One bot, or one bot per service? One bot + a named prefix per message gives attribution without N tokens to rotate. Per-service bots cost one BotFather registration each and buy per-chat mute control.
Destination: DM, or one private group? A group lets you mute/ archive the machine channel independently of your DM list and add peers later; a DM is one less thing to set up.
Do you even have a Telegram account? A bot cannot be created without one. If not, this plan reopens Signal (spare SIM being the robust door there) and the paid Fragment anonymous number is the only Telegram way to avoid a number entirely.
## Decision (2026-10-18, Frank): move machine traffic to **Telegram**, not a second Signal number
> Alter this issue to switch this functionality over to Telegram (assuming Telegram allows number-less signup)
The assumption is **half right, and right where it matters**:
- **A Telegram *bot* has no phone number at all.** It is created by messaging `@BotFather` and authenticates with a token. That kills the whole "where does the machine get a number" problem — no SIM, no rented DID, no SMS/voice confirmation.
- **A Telegram *user account* still needs a number.** Telegram's official no-SIM signup works by registering against a blockchain **anonymous number bought on Fragment** (paid, and it takes an existing account to buy one) — [telegram.org/blog/ultimate-privacy-topics-2-0](https://telegram.org/blog/ultimate-privacy-topics-2-0). So "free numberless signup" does not exist for a user identity. We do not need one.
Signal stays out of machine traffic; the existing `signal-cli` account (your mobile) is left alone.
## Why the current path is broken (unchanged root cause)
`scripts/signal-relay.py` hardcodes **both** sides of every message to the same identity:
```python
SIGNAL_ACCOUNT = "+12062476336"
SIGNAL_TO = "+12062476336"
```
Signal delivers a message sent from a number to itself as a **note to self**, and notes to self raise **no notification**. Verified on the host today: `signal-cli 0.14.7`, `listAccounts` returns exactly one account, `+12062476336`, with `Messages have been last received 46 days ago` — a send-only identity, exactly as the symptom predicts.
For completeness of the Signal option set: `signal-cli 0.14.7`'s `register` is phone-number-only (`Register a phone number with SMS or voice`), Signal's numberless **Signal Login** is a *paid, one-time* registration still in Android beta with **no signal-cli path**, and Signal **usernames** only hide a number from people you message — registration still needs one. So Telegram is strictly the cheaper door: the machine identity costs nothing and needs no hardware.
## Verified precondition
The Bot API is reachable from Dankclaw with no proxy — a deliberately bogus token, so this proves DNS + TLS + the API path, not auth:
```
curl -s -o /dev/null -w '%{http_code}' https://api.telegram.org/bot123:abc/getMe
getMe http=401 dns=0.017s connect=0.166s tls=0.323s total=0.470s
```
## Plan
1. **You create one bot** in Telegram: message `@BotFather` → `/newbot` → pick a name and a username ending in `bot`. You get a token shaped `123456789:AA...`.
2. **The token never enters the repo or the command line.** It goes in `/home/dank/.config/secrets/telegram-relay.env` (mode 600) as `TELEGRAM_BOT_TOKEN=...`, pulled in by `EnvironmentFile`. The repo carries the *path* and the non-secret tunables only, same rule as every other secret here (and the same rule a HF token broke on 2026-09-16: a token in `curl -H` argv is world-readable through `/proc/<pid>/cmdline`).
3. **The bot cannot open a conversation** — Telegram requires the human to message the bot first. So: send the new bot one message (and/or add it to a private group and talk there), then the relay resolves your numeric `chat_id` from `getUpdates` and posts to it. One-time interactive step, which is why this issue is yours.
4. **`scripts/signal-relay.py` becomes `scripts/telegram-relay.py`** — same listener contract (bind `192.168.0.143:18093`, the one address a bridge container can actually reach; iptables still admits only the podman bridge subnet), same `format_group` message text, same 15-minute dedupe, same `MAX_INSTANCES` cap. `POST https://api.telegram.org/bot$TOKEN/sendMessage` with `chat_id` + text replaces the `signal-cli send`; a missing token file logs by name instead of dying silently.
5. **Multiple recipients are a list**, `TELEGRAM_CHAT_IDS`, so a second human or a future agent target is one line — the per-service attribution problem this issue raised disappears: the machine identity is one bot, and every message names its alert.
## Cost of the swap, stated plainly
- Telegram is **cloud-stored** (MTProto client-server); Signal is end-to-end sealed-sender. Alert payloads carry hostnames, service names and firing rules — no credentials — so this is an acceptable disclosure, but it *is* a disclosure and it is recorded here as one.
- The **bot token is a bearer credential**: anyone holding it can send as the fleet bot. Mode 600, out of argv, out of git, out of logs.
- Bot send limits (~1 msg/s per chat, ~30/s global) are far below the 15-minute dedupe window, so no risk of a Telegram 429 storm from a misconfigured rule.
- Rollback is a file move: the Signal unit and `signal-relay.py` are retired to `~/.AGENTTRASH/`, not deleted, per the deletion policy.
## Open questions (one decision each)
- **One bot, or one bot per service?** One bot + a named prefix per message gives attribution without N tokens to rotate. Per-service bots cost one BotFather registration each and buy per-chat mute control.
- **Destination: DM, or one private group?** A group lets you mute/ archive the machine channel independently of your DM list and add peers later; a DM is one less thing to set up.
- Do you even **have a Telegram account**? A bot cannot be created without one. If not, this plan reopens Signal (spare SIM being the robust door there) and the paid Fragment anonymous number is the only Telegram way to avoid a number entirely.
dank
changed title from Agents need their own Signal account: alerts land as a silent "note to self" to Machine alerts need their own identity: switch the relay to Telegram (bot token, no phone number)2026-10-18 15:57:56 -07:00
Decision 2026-10-18 (Frank): no action, parked for later. Nothing implemented, nothing deployed — scripts/signal-relay.py keeps running and alerts keep landing as silent notes to self. The open choices (DM vs group, one bot vs per-service, Telegram vs a second Signal account) are parked in #9 with the facts already verified here.
**Decision 2026-10-18 (Frank): no action, parked for later.** Nothing implemented, nothing deployed — `scripts/signal-relay.py` keeps running and alerts keep landing as silent notes to self. The open choices (DM vs group, one bot vs per-service, Telegram vs a second Signal account) are parked in #9 with the facts already verified here.
dank
added the human-only label 2026-10-18 16:01:29 -07:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Decision (2026-10-18, Frank): move machine traffic to Telegram, not a second Signal number
The assumption is half right, and right where it matters:
@BotFatherand authenticates with a token. That kills the whole "where does the machine get a number" problem — no SIM, no rented DID, no SMS/voice confirmation.Signal stays out of machine traffic; the existing
signal-cliaccount (your mobile) is left alone.Why the current path is broken (unchanged root cause)
scripts/signal-relay.pyhardcodes both sides of every message to the same identity:Signal delivers a message sent from a number to itself as a note to self, and notes to self raise no notification. Verified on the host today:
signal-cli 0.14.7,listAccountsreturns exactly one account,+12062476336, withMessages have been last received 46 days ago— a send-only identity, exactly as the symptom predicts.For completeness of the Signal option set:
signal-cli 0.14.7'sregisteris phone-number-only (Register a phone number with SMS or voice), Signal's numberless Signal Login is a paid, one-time registration still in Android beta with no signal-cli path, and Signal usernames only hide a number from people you message — registration still needs one. So Telegram is strictly the cheaper door: the machine identity costs nothing and needs no hardware.Verified precondition
The Bot API is reachable from Dankclaw with no proxy — a deliberately bogus token, so this proves DNS + TLS + the API path, not auth:
Plan
@BotFather→/newbot→ pick a name and a username ending inbot. You get a token shaped123456789:AA..../home/dank/.config/secrets/telegram-relay.env(mode 600) asTELEGRAM_BOT_TOKEN=..., pulled in byEnvironmentFile. The repo carries the path and the non-secret tunables only, same rule as every other secret here (and the same rule a HF token broke on 2026-09-16: a token incurl -Hargv is world-readable through/proc/<pid>/cmdline).chat_idfromgetUpdatesand posts to it. One-time interactive step, which is why this issue is yours.scripts/signal-relay.pybecomesscripts/telegram-relay.py— same listener contract (bind192.168.0.143:18093, the one address a bridge container can actually reach; iptables still admits only the podman bridge subnet), sameformat_groupmessage text, same 15-minute dedupe, sameMAX_INSTANCEScap.POST https://api.telegram.org/bot$TOKEN/sendMessagewithchat_id+ text replaces thesignal-cli send; a missing token file logs by name instead of dying silently.TELEGRAM_CHAT_IDS, so a second human or a future agent target is one line — the per-service attribution problem this issue raised disappears: the machine identity is one bot, and every message names its alert.Cost of the swap, stated plainly
signal-relay.pyare retired to~/.AGENTTRASH/, not deleted, per the deletion policy.Open questions (one decision each)
Agents need their own Signal account: alerts land as a silent "note to self"to Machine alerts need their own identity: switch the relay to Telegram (bot token, no phone number)Decision 2026-10-18 (Frank): no action, parked for later. Nothing implemented, nothing deployed —
scripts/signal-relay.pykeeps running and alerts keep landing as silent notes to self. The open choices (DM vs group, one bot vs per-service, Telegram vs a second Signal account) are parked in #9 with the facts already verified here.