0

The message in telegram can be forwarded from users/chats/channels to other users/chats/channels. The message type has a fwd_from field with type messageFwdHeader - the from_id field inside of this object describes where the message comes from (user or channel). If we're talking about a channel who posted this message, we would have channel_post field populated with the message ID.

All seems to make sense. Someone posted a message, it got forwarded or re-forwarded any number of times, but we still have the ID of the original author as well as message's ID.

But there are also saved_from_peer and saved_from_msg_id fields. Citing from the docs:

saved_from_peer [...] Only for messages forwarded to the current user (inputPeerSelf), full info about the user/channel that originally sent the message

saved_from_msg_id [...] Only for messages forwarded to the current user (inputPeerSelf), ID of the message that was forwarded from the original user/channel

But... we already seem to get both of these pieces of data inside from_id and channel_post fields, don't we?

We can compare the definitions of from_id vs saved_from_peer: The ID of the user that originally sent the message vs [...] full info about the user/channel that originally sent the message.

The types of the fields are the same, the definitions have no significant difference.

What do these fields actually mean?

winwin
  • 958
  • 7
  • 25

2 Answers2

1

As the docs state saved_from* fields are utilized on forwarded messages to yourself, the "Saved Messages".

Not much more into it, ignore it if you're not dealing with saved messages, this exists incase you wanted to go back to the context in joined groups too, since channel_post is only for channels if forwarded outside of saved message.

it gives you the message id in the saved_from peer and naturally the saved from peer.

the from_id is utilized as the circular avatar of user who sent the message, which can be equal to saved_from peer sometimes (when message was sent in broadcast, no sender is visible so will be the channel itself)

MustA
  • 932
  • 5
  • 8
  • For the most part your answer seems to be correct, however I just tested some cases and found out another interesting detail: these also get populated for messages inside discussion groups which were auto-forwarded from the main channel. They contain references to the message inside the channel and are duplicate of `from_id` and `channel_post` fields in the cases when the channel **itself** posted something. They become meaningful once the channel actually **forwarded** something from another channel/user, thus `from_id` and `channel_post` would be this user's/channel's IDs. – winwin Apr 10 '23 at 15:45
  • This still doesn't change the fact that you can and should ignore them, they're only used for metadata and are for GUI clients to have the forwarded message have an avatar in discussion groups. channel_post is used when you click the avatar, and also exists in saved messages when saved from msg id does exists (arrow click next to the message). it is something up to server devs and backwards compatibility for why they repeat data. that's aside, the general use of those two fields and why they exist is same i mentioned – MustA Apr 10 '23 at 18:35
  • Check out my answer. It's not for backwards compatibility, it actually serves a purpose outside of the "Saved Messages" domain. – winwin Apr 10 '23 at 18:42
0

@MustA got the main part of it, I noticed some pecurialities.

Imagine we've got channel A, which has discussion group B linked to it. Every time we're gonna be adding a new message to A and seeing what's happened to B.

We post message M1 to A, it automatically gets forwarded to B, thus creating a copy of M1 inside B. This copy would have fwd_from set to:

{
  "from_id": "channel A id",
  "channel_post": "id of M1 inside A",
  "saved_from_msg_id": None,
  "saved_from_peer": None
}

It's easy.

But let's add channel C to the mix. We'd forward message M2 from C into A, and it gets auto-forwarded to B. The fwd_from would then look like:

{
  "from_id": "channel C id",
  "channel_post": "id of M2 inside C",
  "saved_from_msg_id": "id of M2 inside A",
  "saved_from_peer": "channel A id"
}

Do you see what happened? from_id and channel_post always point to the original author, whilst saved_from_peer and saved_from_msg_id point to the last source of this message, in our case channel A. And since A isn't the original author of the post, we don't receive it inside the from_id field.

The same goes for forwarding user U's message M3 to the channel:

{
  "from_id": "user U id",
  "channel_post": None,
  "saved_from_msg_id": "id of M3 inside A",
  "saved_from_peer": "channel A id"
}

So in the end the field actually has more capabilities than the official docs say.

winwin
  • 958
  • 7
  • 25