Keep channel attribution on forwarded messages

[aazimin]

Problem

message_to_dict reads only two fields off fwd_from:

fdate = getattr(fwd, "date", None)
fname = getattr(fwd, "from_name", None)

Telegram populates from_name only when the original author hides their profile. For an ordinary forward from a channel the origin lives in fwd_from.from_id, which is never read — so the MCP output is just:

"forwarded": {"date": "2026-07-15T12:01:02+00:00"}

Everything the client displays as "Forwarded from …" is lost, and that is the common case rather than an edge one. An agent consuming this cannot tell which channel a forwarded post came from, or link back to it.

Change

Also read Telethon's msg.forward wrapper. It resolves the forward peer from entities already present in the same response, so this adds no extra API call and stays synchronous.

New keys inside forwarded, each omitted when absent, matching the file's existing style:

Key	From
from_chat	channel/group title, or the user's full name
from_username	public @username of the origin
from_chat_id	numeric peer id
from_user	sender name, for user-to-user forwards
channel_post	fwd_from.channel_post
post_author	fwd_from.post_author
post_link	built permalink, see below

post_link is https://t.me/<username>/<post> for a public channel and the members-only https://t.me/c/<internal_id>/<post> form otherwise.

Same message as above, after the change:

"forwarded": {
  "date": "2026-07-15T12:01:02+00:00",
  "from_chat": "Полезный Парфун",
  "from_username": "ParfunA",
  "from_chat_id": -1001626974925,
  "channel_post": 6279,
  "post_link": "https://t.me/ParfunA/6279"
}

from_name is still emitted exactly as before, so hidden-profile forwards keep working unchanged. Names go through sanitize_name, consistent with the rest of the function.

Tests

tests/test_forward_attribution.py covers public-channel, private-channel, user-to-user, hidden-profile and non-forward messages. Full suite: 118 passed. black and the pre-commit flake8 selection are clean.

Verified against

A real forward fetched through get_history — the post_link above resolves to the original post.

🤖 Generated with Claude Code

[chigwell]

Correct me if I'm wrong, but t.me no longer works.

[aazimin]

Checked before changing anything — t.me is up. It serves 200 right now from two different networks, and whois reports the domain ACTIVE (no serverHold):

$ curl -sI https://t.me/ParfunA/6279   → HTTP/2 200
$ whois t.me | grep -i status          → status: ACTIVE

The outage behind your concern was real though: on 2026-07-13 the .me registry put t.me on serverHold over an OFAC listing — a sanctioned entity had used a Telegram channel as a contact address — and every t.me link on earth broke for roughly a day. It was restored on 2026-07-14. During the outage telegram.me kept resolving.

For what it's worth, the repo already emits t.me links elsewhere — tools/profile.py:266 builds f"https://t.me/{ch_username}", and get_message_link is documented as exporting a t.me/... link (via ExportMessageLinkRequest, where Telegram itself formats the result).

Still, your instinct holds: one registry decision can take every permalink down at once, and hardcoding the domain in a new place makes that worse. So I've pushed a follow-up that stops hardcoding it:

LINK_DOMAIN = os.getenv("TELEGRAM_LINK_DOMAIN", "t.me")

Default is unchanged, and anyone who needs telegram.me (or whatever comes next) can switch without a code change. Covered by a test that overrides the domain.

Happy to drop post_link entirely if you'd rather not have a built URL in the payload at all — the raw parts (from_username, from_chat_id, channel_post) are all there for a caller to assemble. Just say the word.