Meaning of `saved_from_peer` and `saved_from_msg_id` inside `MessageFwdHeader` type

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?

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 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.