Problem
Follow-up to #114 (three-axis triage gate + deterministic news rail). Non-blocking; noted by review on that PR.
When a message from a news-flagged group is forwarded onto the news rail, the feed item's user-facing source field is set by the calling gateway. Two of the three gateways pass a readable name; Signal does not:
scripts/telegram-gateway.py:888 → _forward_news(question, sender_name or handle, group_id, lang)scripts/whatsapp-gateway.py:1030 → _forward_news(question, sender_name or (group_id if is_group else sender), group_id, lang)scripts/signal-gateway.py:1146 → _forward_news(question, group_id if is_group else sender, group_id, lang)
The Signal path has no readable name to pass because _forward_to_inbox(question, lang, sender, group_id=None, files=None) (scripts/signal-gateway.py:1118) carries no group-name parameter — unlike Telegram/WhatsApp, whose _forward_to_inbox take a sender_name. So a Signal group news item shows the raw group_id (opaque base64 on Signal) as its source on the news page, while the same class of item from Telegram/WhatsApp shows a human-readable name.
Impact
Cosmetic only — the item is filed, scored and ranked correctly; just its source label is unreadable for Signal groups. No data loss, no crash.
Fix sketch
Thread a resolved group name into the Signal call site and pass it to _forward_news, mirroring the other two gateways:
- Add an optional group-name parameter to Signal's
_forward_to_inbox (or resolve it inside), sourced from the gateway's existing groups roster (GET /groups already exposes group names).
- Fall back to
group_id when no name resolves, so behaviour degrades to today's output rather than erroring.
Keep it consistent with the sender_name or <fallback> pattern the Telegram/WhatsApp call sites already use.
Out of scope
Individual-sender Signal news items already pass sender (a number); giving those a contact name is a separate, larger contact-resolution concern and not part of this issue.
Problem
Follow-up to #114 (three-axis triage gate + deterministic news rail). Non-blocking; noted by review on that PR.
When a message from a
news-flagged group is forwarded onto the news rail, the feed item's user-facingsourcefield is set by the calling gateway. Two of the three gateways pass a readable name; Signal does not:scripts/telegram-gateway.py:888→_forward_news(question, sender_name or handle, group_id, lang)scripts/whatsapp-gateway.py:1030→_forward_news(question, sender_name or (group_id if is_group else sender), group_id, lang)scripts/signal-gateway.py:1146→_forward_news(question, group_id if is_group else sender, group_id, lang)The Signal path has no readable name to pass because
_forward_to_inbox(question, lang, sender, group_id=None, files=None)(scripts/signal-gateway.py:1118) carries no group-name parameter — unlike Telegram/WhatsApp, whose_forward_to_inboxtake asender_name. So a Signal group news item shows the rawgroup_id(opaque base64 on Signal) as its source on the news page, while the same class of item from Telegram/WhatsApp shows a human-readable name.Impact
Cosmetic only — the item is filed, scored and ranked correctly; just its
sourcelabel is unreadable for Signal groups. No data loss, no crash.Fix sketch
Thread a resolved group name into the Signal call site and pass it to
_forward_news, mirroring the other two gateways:_forward_to_inbox(or resolve it inside), sourced from the gateway's existing groups roster (GET /groupsalready exposes group names).group_idwhen no name resolves, so behaviour degrades to today's output rather than erroring.Keep it consistent with the
sender_name or <fallback>pattern the Telegram/WhatsApp call sites already use.Out of scope
Individual-sender Signal news items already pass
sender(a number); giving those a contact name is a separate, larger contact-resolution concern and not part of this issue.